Automated enforcement of security policies in cloud and hybrid infrastructure environments

ABSTRACT

To prevent un-authorized accesses to data and resources available in workloads on an organization&#39;s or enterprise&#39;s computer network, various improvements to automated computer network security processes to enable them to enforce network security policies using native network security mechanisms to control communications to and/or from workload units of applications running on different nodes within hybrid computer network infrastructures having both traditional hardware resources and virtual resources provided by private and public cloud infrastructure services.

RELATED APPLICATION

This application claims the benefit of U.S. provisional application62/449,571, filed Jan. 23, 2017, U.S. provisional patent application62/450,001, filed Jan. 24, 2017, and U.S. 62/477,376, filed Mar. 27,2017, each of which is incorporated by reference herein for allpurposes.

FIELD OF INVENTION

The invention relates to computer processes for securing computernetworks against unauthorized access.

BACKGROUND

There are many existing mechanisms and devices that can enforce securitypolicies at the network level in different points of the network or thecomputer system stack. These include network equipment such as routers,firewalls, Intrusion Prevention Systems (IPS), as well as softwarecomponents running in operating systems, hypervisors, and virtualmachines. Examples include Linux IP tables, Linux open vSwitch,Microsoft Windows Firewall, VMware NSX distributed firewall, etc. Inaddition, public and private cloud service providers—those who own andprovide the hardware, network connections, underlying software, andother services to support running of third party application programs onvirtual machines or in containers and the like—offer APIs to configuretheir virtual firewalls that enforce network communication for theirvirtual machines and container instances. Examples include Amazon®security groups and OpenStack® security groups. These mechanisms operateat the network level and are configured with rules specifying networkelements. The phrase “cloud-native controls” will refer to built-insecurity controls offered by public and private cloud service providers.

A network security enforcement mechanism—typically implemented as aprocess performed by a computer under the control of stored softwareinstructions, but also in hardware configured by software—interceptsnetwork traffic at a given point along the traffic's communication pathand checks the traffic against a set of network security rules. Anetwork security rule is usually specified by a set of matchingconditions and an action. Every packet processed by the enforcementmechanism may be checked against all the security rules. If theconditions specified in a rule is satisfied by the packet, the rule issaid to match the packet. In general, more than one rule can match apacket. In this case a priority mechanism is used to select one of thematching rules and the action specified by the higher priority rule isapplied to the packet.

Many different types of actions can be specified in a rule, two of whichare allow and block. An “allow” rule allows the packet to continue onits path to its destination and a “block” rule discards the packet.Matching conditions of a rule can specify a set of conditions thatcommon fields in a network packet should satisfy. These conditions mayspecify a value, a range of values, or a prefix that a packet field mustsatisfy. Packet fields commonly used in network security rules include:the IP protocol number in the packet IP header field; the destination IPaddress in the packet IP header field; the source IP address in thepacket IP header field; the destination port number in the TCP or UDPheader if the IP protocol is TCP or UDP; and the source port number inthe TCP or UDP header if the IP protocol is TCP or UDP. Some networksecurity mechanisms also use other packet fields such as layer2 MACaddresses, frame type, and VLAN id. They can also use metadatainformation that is not present in the packet data but can be extractedfrom the network processing environment such as for example the port inwhich the packet was received on a multiport device such as a networkswitch.

Different network security enforcement mechanisms offer differentcapabilities. Some enforcement mechanisms may not support both types ofrule actions. For example, Amazon AWS security groups only support“allow” actions, and do not support “block” actions. Enforcementmechanisms differ in the degree of isolation from the workload unit.Enforcement mechanisms implemented at the operating system level aremore susceptible to security threats that exploit vulnerabilities ofapplications running on the same operating system. If a threat is ableto gain root access in an operating system it can disable the securityrules of the enforcement mechanism. Enforcement mechanisms implementedoutside the operating system are in a different security domain and aremuch less vulnerable to these threats. Among these, enforcementmechanisms implemented in separate devices, such as network firewall andswitches, offer the lowest degree of vulnerability. A network securityenforcement mechanism can offer one of several possible degrees ofisolation in increasing order of isolation: same software domain as theworkload unit; different software domain; different hardware domain.

Some enforcement mechanisms may be configured to generate a notificationwhen a packet is discarded because it violates the network securitypolicy. In general security mechanisms implemented in operating systemsand hypervisors can be instrumented or programmed to generate thesenotifications. Network devices such as firewall and cloud networksecurity API's usually do not offer this capability. Some enforcementmechanisms implemented at the operating systems can support matchingrules that specify a particular application program. Some enforcementmechanisms have a maximum number of rules that be configured.Enforcement mechanisms in public cloud providers are examples of thesemechanisms.

A network switch is not able, for example, to enforce policy rules onnetwork packets sent between two virtual machines hosted in the samehypervisor, since these packets are not processed by the network switch.Physical network switches do not process packets exchanged betweenvirtual machines hosted in the same physical server. Enforcementmechanisms implemented in an operating system will be able to interceptmore traffic between applications running. Similarly, network securityenforcement mechanisms implemented in a hypervisor and mechanismsoffered by cloud service providers can intercept traffic between guestmachines.

SUMMARY

To prevent un-authorized accesses to data and resources available inworkloads on an organization's or enterprise's computer network, variousimprovements to automated computer network security processes to enablethem to enforce network security policies using native network securitymechanisms to control communications to and/or from, and thus preventunauthorized access to, workload units of applications running ondifferent nodes within hybrid computer network infrastructures havingboth traditional hardware resources and virtual resources provided byprivate and public cloud infrastructure services.

The various improvements are capable of supporting applications withinhybrid computer network infrastructures having both traditional hardwareresources and virtual resources provided by private and public cloudinfrastructure services providers. Representative examples of systemsand processes implementing one or more of these improvements perform oneor more of the following: discovering real time network flows;discovering native infrastructure changes; enforcing micro-segmentation;provisioning of application security policy to security mechanismsnative to cloud services and hardware; and continuously monitoringnetwork flows to detect, block and/or quarantine threats, and to monitorsecurity mechanisms to ensure the security mechanisms are configured asdefined by policies, fixing detected misconfiguration.

The security systems and processes described below are implemented assoftware running on a computer server in communication with varioussecurity mechanisms native to an organization's or enterprise's datanetwork infrastructure, and are useful for securing applications runningnot only virtual computing infrastructures, including those availablethrough public networks (the Internet) and private wide area networks,but also in hybrid computer network infrastructures combing traditionalphysical networks and servers with virtual computing infrastructures.

According to one aspect of a representative example of a computernetwork security system, one or more processes running on computers incommunication with an organization's computer network automaticallyconfigure native, network level security mechanisms within the computernetwork using security policies specified by the organization at anapplication level. The one or more processes map application levelsecurity rules to network level security rules, which are thenprovisioned to one or more infrastructure network security enforcementmechanisms at a plurality of different points with the computer system'sinfrastructure. These points include any one or more of the following:network devices (such as routers, switches and firewalls), operatingsystems, hypervisors, and public and private cloud service providers.

In one representative example, these processes automatically mapapplication level security rules to network level security rules of aplurality of network security mechanisms based on one or more of thefollowing considerations: the type of application level rules, theproperties of the computing resources hosting the application, and thecapabilities of the available network security enforcement mechanisms.

In yet another aspect of a representative security system, the processesautomatically map application level security policy specifications intonetwork level security enforcement rules that are provisionedautomatically to one or more network security enforcement mechanisms atdifferent points of the system infrastructure, including networkdevices, operating systems, hypervisors, and public and private cloudprovider.

By configuring multiple network security enforcement mechanisms in acoordinated way, representative example of certain process describedbelow are capable of taking advantage of different features provided byeach network security enforcement mechanism to provide a more effectiveglobal application security that is stronger than the security providedby each individual mechanism in isolation.

Enterprises or other very large organizations often have many lines ofbusiness, departments, projects, and other sets or groupings of people,responsibilities, and resources. These groupings may be givenresponsibility for operating and managing a subset of the enterprise'scomputing network infrastructure resources. In accordance with yetanother aspect of a representative example a computer network securitysystem, the computer network security system implements processes forenforcing global computer network security policies across an enterprisebut allows local groups or organizations within the enterprise toestablish communication security policies infrastructure resources forwhich they have responsibility, without having to seek approval from acentral security administrator. In this representative example, a largeenterprise may enforce global network security across multiple lines ofbusiness or departments while giving smaller groups within theenterprise the agility to deploy new application or modify securitypolicies of existing applications, without having to wait for centralapproval, which may slow down application deployments. Each subgroup mayuse the computer network security system to define its own policiesspecific to their applications and environments, provided they satisfyglobal enterprise constraints defined by global security administrators.Such as computer network security system is capable of permitting fast,self-service capability for creating network policies by individualgroups, while preserving the control for global security organizationsto define enterprise wide security requirements that the self-servicepolicies need to satisfy.

These and other aspects of systems and process for securing applicationsin computer networks, particularly those with hybrid infrastructurescomprising cloud services, are embodied in a representative example of acontextual security platform described below.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic representation of a representative example ofhardware components of a programmable computer.

FIG. 2 is a schematic of a contextual security platform interacting withsecurity components and databases storing application policies andinfrastructure information.

FIG. 3 is a schematic drawing of a representative example ofdistribution of workload units of and workloads on multiple nodesinterconnected with users through a computer network, such as theInternet, and showing permitted communication connections specified bythe security policy illustrated by FIG. 4

FIG. 4 is a simplified, representative example, presented in the form ofa table, of a set of an application level set of security policies orrules for the example of FIG. 3.

FIG. 5 is a schematic representation of a contextual security platformcommunicating with security mechanisms native to the computerinfrastructure hosting workload units that have been distributed betweena data center and a private or public cloud service provider.

FIG. 6 is a flow chart illustrating a representative process for mappingan application level security policy rule to network level securitypolicy rules that may be used by the contextual security platform.

FIG. 7 is a flow chart illustrating a representative process forselecting the set of network enforcement mechanisms.

FIG. 8 is a flow chart illustrating a representative process fordiscovering and applying tags for resources.

FIG. 9 illustrates a flow chart representing the basic steps of anautomated process within computer network security application forassigning an attribute to a resource.

FIG. 10 illustrates a flow chart illustrating the basic steps ofautomated assignment of tags by a computer network security applicationbased on discovered tags or resource properties.

FIG. 11 illustrates a flow chart representing the basic steps of anautomated process of the computer network security application forindirect assignment of tags based on logical group membership.

FIG. 12 illustrates a flow chart representing an automated process ofthe computer network security application for assignment of attributesacross organizations (with approval) and constraint on attributes.

FIG. 13 illustrates a flow chart representing a method for automating aprocess by the computer network security application for usingcommunication constraint policies to check communication policy rulesthat might be created by a local organization.

FIG. 14 illustrates a flow chart for a sub-process of FIG. 13,representing a method for automated checking of a single communicationpolicy rule against communication constraint policies.

FIG. 15 illustrates a flow chart of a sub-process for use as part of theprocesses of FIGS. 13 and 14, for enabling the computer network securityapplication to check matching of an “allow” constraint rule with acommunication policy that may be created by a local organization.

FIG. 16 illustrates a flow chart of a sub-process for is as part of theprocesses of FIGS. 13 and 14, illustrate a method for enabling thecomputer network security application to perform a process forautomatically matching a “block” constraint rule with a policy rule.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

In the following description, like numbers refer to like elements.

The systems and processes described below are implemented using softwareprograms running on programmable computers. A programmable computer is amachine that is, in general terms, typically comprised of at leastmemory for storing one or more programs of instructions and a processor,such as a central processing unit (CPU), for performing a sequence ofarithmetical and logical operations based on the program instructionsstored or otherwise read or received by the computer.

FIG. 1 is a schematic illustration of the basic hardware components of arepresentative programmable computer system. Computer 100 comprises oneor more processors, generally represented by processor 102, whichcomprise a CPU, for reading and executing instructions. Steps forcarrying out the processes are encoded in one or more sets ofinstructions, or programs.

Computer 100 includes a processor 102. The processor is representativeof implementations having one or more central processing units (CPUs), agraphics processing unit (GPU), other types of processors, andcombinations of CPUs, GPUs, and other types of processors. The processorcommunicates with a main or working memory 104 and a storage memory 106over one or more buses represented by bus 108. The main or workingmemory is intended to be generally representative of short-term memoryused by the processor for storing instructions being executed and otherdata being processed, such as random access memory (RAM), includingcache memory. Storage memory is representative of longer-term memory forstoring program instructions and data structures, such as hard disks andsolid-state disks. Bus 108 is intended to be representative of all typesof bus architectures and other circuits for enabling communicationbetween the processor 102 and other components of the computing machine.

The computer 100 may also be connected with other hardware to form acomputing system or to implement a special purpose device that utilizesthe computer's processing for control, communication, or otherfunctions. For example, if intended to interact with a person, it maycommunicate with a user through visual display 110. Examples of visualdisplays include monitors such as liquid crystal displays, projectors,and other devices for creating visually perceptible images. The computermay also include one or more devices for enabling a user to enterinformation, control, and interact with the computing machine and agraphical user interface presented on the visual display. These arecollectively designated 112 and may include, for example, depending onthe computing machine, a keyboard, a mouse or track pad, a touchscreen,a microphone, and similar devices for providing interaction. A mediareader 114 for reading removable media, such as an optical disk drivethat reads optical media or a memory card reader, enables the computingmachine to read data from and/or write data to removable data storagemedia.

The computer may also communicate with other types of other input andoutput devices through various type interfaces. These devices aregenerally designated 116. Examples include cameras, a Global PositioningSystem (GPS) receiver, and environmental sensors, such as temperature,light, and acoustic sensors, accelerometers, and gyroscopes. Tocommunicate with other computers (or devices in which computers havebeen embedded), the computer may be connected to one or more networkinterfaces 118 that enables the computing machine to communicate withother computers and devices using known networking protocols. Thenetwork interfaces may be wired, optical, or wireless.

Program instructions to executed by the processor and data structureswritten or read by such processes, are stored on machine or computerreadable media. Examples of such computer readable media include, butare not limited to, working memory 104, storage memory 106, as well asremovable media being read by reader 114, While the machine-readablemedium in the example embodiment can be a single medium, the termsmachine readable medium and computer readable medium are generallyintended to also include, unless the context clearly indicatesotherwise, multiple media, and can be centralized or distributed amongseveral computing machines.

A processor can be a microprocessor, a special purpose processor, or acombination of one or more processors of the same or different types. Afew examples of machines or devices comprising or containingprogrammable computers include mainframe computers, mini computers,personal computers (PC), web appliances, network routers, switches,bridges, hardware firewalls, mass data storage devices tablet computers,set-top boxes, smartphones, personal digital assistants (PDA), cellulartelephones. This foregoing list is not to be limiting. Furthermore,multiple computers may implement a process, each performing only a partof the process, or a separate instance of the process.

The term “non-transitory machine-readable medium” means any tangiblemedium or media, but not transitory signals, that is capable of storing,encoding, or carrying instructions for execution by the computingmachine and that cause the computing machine to perform any one or moreof the processes described below, or that is capable of storing,encoding, or carrying data structures used by or associated with suchinstructions. Examples of non-transitory machine-readable media include,but are not limited to, nonvolatile memory, including by way of example,semiconductor memory devices (e.g., Erasable Programmable Read-OnlyMemory (EPROM), Electrically Erasable Programmable Read-Only Memory(EEPROM), and flash memory devices), magnetic disks such as internalhard disks and removable disks, magneto-optical disks, and CD-ROM andDVD-ROM disks.

Although not illustrated, most programmable computers have an operatingsystem. An operating system (OS) is set of computer programs that managecomputer hardware and software resources and provides common servicesfor application and other programs that are executed by the computer. Asexplained below, a single hardware computer can be used to supportmultiple, separate virtual computing environments for supportingexecution of a software application. Processes described below can beprogrammed as an application and executed directly by a hardwarecomputer or in a virtualized environment.

A programmable computer may be embedded into a special purpose devicefor providing the logic for controlling the device and/or extending itsfunctionality and include, or be combined with, a number of otherelements, including ports for connecting, for example, keyboards andvisual displays to allow a person to interact with the computer, andnetwork interfaces for allowing the computer to communicate with othercomputers over a network. Examples of computers include desktop andlaptop computers, computers that act as servers, routers, switches,mobile devices, embedded computing systems, and any type of machine withone or more central processing units for executing instructions toperform programmed processes.

A computer system may also be emulated using software running on ahardware computer system. This virtualization allows for multipleinstances of a computer system, each referred to as virtual machine, torun on a single machine. Each virtual machine behaves like a computersystem running directly on hardware. It is isolated from the othervirtual machines, as would two hardware computers. Each virtual machinecomprises an instance of an operating system (the “guest operatingsystem”). There is a host operating system running directly on thehardware that supports the software the emulates the hardware. Theemulation software is called a hypervisor. A “container” or virtualcontainer is another form of a virtualization environment for runningapplications. Rather than emulating an entire computer, containeremulates, from the perspective on application, an operating system. Acontainer can be thought of as a virtual operating system. Thecontainers share a single instance of a host operating system running ahardware computer. Each instance of these virtual computing entities—thevirtual machine, containers, etc.—behaves generally as would a separatecomputer and can be configured and operated as such as part of anenterprises network infrastructure, with separate network accesscontrols configured for each instance using the virtualizationenvironments security mechanisms.

One of the benefits of virtualization environments is that computers canbe quickly created and deployed—“spun up”—as the need arises andconfigured as needed. Although such virtualization environments can beprivately deployed and used within local area or wide area networksowned by an enterprise, a number of “cloud service providers” hostvirtualization environments accessible through the public internet (the“public cloud”) that is generally open to anyone, or through private IPor other type of network accessible only by entities given access to it(a “private cloud.”) This “infrastructure as a service” (IAAS) allowsenterprises to access virtualized computing systems through the publicInternet. Examples of public IAAS cloud providers include Amazon AWS,Microsoft Azure and Google GCP. Examples of private cloud environmentsinclude OpenStack and VMware vCenter.

Unless otherwise indicated, the term “computer” will be used to refer tonot only hardware computers but also virtualized computing entities forsupporting execution of an application, examples of which includevirtual machines, virtual containers, based-file systems, thin virtualmachines and the like.

Referring now to FIG. 2, the processes described below arerepresentative examples of processes a contextual security platform 202.The contextual security platform comprises an application program, or aset of application programs, that is stored on computer readable andcomprises instructions executed by one or more computers to perform oneor more of the processes described below.

The contextual security platform implements a number of differentprocesses. These processes include the following: discovering real timenetwork flows between nodes hosting workload units (see FIG. 3);discovering of native infrastructure changes; enforcingmicro-segmentation; mapping and provisioning of application levelsecurity policies to security mechanisms native to infrastructure of thecomputer network with which the contextual security platform is used;and continuously monitoring network flows and security mechanisms todetect, block and/or quarantine threats. Together, these processesestablish a system for protecting data and resources available inworkloads from un-authorized users and applications by preventingcommunication to and from workload units and allowing only authorizedcommunication in cloud based, physical, and/or hybrid computer networkinfrastructures. However, each one of these processes could,individually, be useful in a computer network security system. Thecontextual security platform is an example of how each may be embodiedin a way that allows them to work together.

The contextual security platform 202 functions as an engine or managerfor implementing the logic for carrying out the processes. Data used bythe processes of the contextual security platform is written to, andread from, one or more databases, represented by generic database 204,which store the information. The information being stored includesapplication level security policies 206, a listing of logical groups(explained below) 208, a system model comprising a database 210 ofinformation on resources within the infrastructure of the computernetwork being secured, and a collection of information on contextualnetwork flows 212. An application programming interface 214 may also beprovided for supporting a user interface into the system as well asthird-party software systems, as represented by blocks 216 and 218,respectively.

The contextual security platform 202 communicates with the applicationprogramming interface of one or more cloud service providers,representative examples of which are indicated by blocks 220, 222 and224. The contextual security platform can support any number of cloudservice providers, limited only by the scalability of the particularimplementation. The contextual security platform exchanges messages withthe cloud service providers using the native application programminginterfaces provided by the services. The type of information thecontextual security platform can request and receive from the API ofeach of the cloud service provider depends on the particular service.However, it preferably includes information on network resourcesprovided by the service that are part of the infrastructure of thenetwork being secured, as well as information on traffic flows to andfrom the network resources, as represented by arrow 226 and 228,respectfully. As a user might use a user interface for the cloud serviceprovider to do so, the contextual security platform may also use theapplication programming interface to configure security mechanismsnative to the services provided by the cloud service providers asindicated by arrow 230. Messages to and from the application programminginterfaces many sent using protocols supported by the cloud serviceproviders' APIs. Typical examples include IP, TCP, HTTP, HTTPS and othersimilar types of network protocols.

For traditional physical resources that do not offer an API, theresources are discovered using software programs called agents,indicated by blocks 232, that are installed on the physical resources.Two examples of physical resources, 234 and 236 are represented, in thefigure. The same types of information agents communicate in a waysimilar to communications taking place over IP networks using, forexample, TCP connections. As indicated by arrows 238, 240 and 242,messages are sent between the contextual security platforms in theagents. This information preferably includes receiving from the agentsinformation similar to the exchanged with the cloud service providersnamely information on the resource and data flows to and from theresource, as represented by arrows 238 and 240. It also preferablyincludes the ability to configure native security mechanisms that arepart of that resource by sending messages to the agent containingconfiguration information, as represented by arrow 242.

In addition to traditional physical resources, agents can also be usedto discover virtual or cloud resources when APIs are not available orwhen a driver plugin for that API has not been developed.

The system model database stores the application and infrastructureinformation needed by the context security platform. These include thelist of managed compute environments and the available network securityenforcement mechanisms in each one of them. It also includes the list ofworkload units, the nodes hosting the workload units and theirassociated parameters. This information can be configured using commandsexposed in an API offered by the policy manager. These commands can begenerated by a User Interface or by any other software system.

The information can be populated by automatic tools that can extractapplication information and enterprise policies from existing enterpriseconfiguration systems, repositories or databases, or can also bemanually entered by system, network and security admins using a userinterface.

Software development and IT operations (DevOps) tools that automaticallydeploy applications can be configured to update workload information inthe system model database when new applications are deployed ordecommissioned. They can also update the database when new workloadunits are added or removed to an existing workload due to applicationscale up and scale down operations. They can also change the mapping ofworkload units to nodes when workloads are migrated. For example, when aworkload is moved from an on-premise datacenter to a public cloudprovider the system model database can be updated with a new mapping ofworkload unit to node and compute environment.

The IP address of a node is used as the IP address of the workload unitshosted in that node. The IP address of the node can be obtained bydifferent mechanisms: 1) It can be queried using the cloud provider APIif the node is hosted on a public or private cloud provider, 2) It canbe queried using the virtualization software manager API if the node ishosted on a virtual environment; 3) It can be provided by an agentrunning on the node; 4) It can be configured by an external softwaresystem; 5) It can be configured using a user interface.

When a workload unit is not managed by the policy manager it may not beassociated with a node, but its IP address may still be needed if theworkload unit offer services to some managed workload unit or need toaccess a managed workload unit. In that case the system model stores theIP address or DNS name associated with the unmanaged workload unit. If aDNS name is used, the corresponding IP address is computed using a DNSlookup operation. The DNS lookup operation can be performed multipletimes by agents running on different regions in different computeenvironments, generating multiple IP addresses. These IP addresses canbe different and depend on the specific region where the DNS lookup isperformed. In that case, when configuring a specific network securityenforcement mechanism, the correct IP address corresponding to thelocation of enforcement point is used.

Some application level policy rules may specify a range of networkaddresses (specified in CIDR or similar notation) as the client orprovider of a service. In that case the network range is used as thesource or destination IP address, respectively, of the network securityrule configured in the enforcement mechanism.

When any infrastructure parameter change, such as for example a workloadunit changing its IP address, an application security policy that usesthat parameter is re-evaluated (all of them are usually reevaluated) andthe corresponding network security enforcement rules are recomputed andupdated on the corresponding enforcement points.

FIG. 3 is a schematic illustration of a scenario of a relatively simpleexample in which users and applications deployed on multiple computersthat are interconnected by a computer network or interconnected computernetworks, such network or interconnected network being generallyrepresented by cloud 300.

An “application” is a computer program or set of programs that, whenexecuted, directs the computer perform useful one or more usefulfunctions or processes. An application will typically have multipleconcurrent processes running one or more computers. Multiple instancesof a single application program may run on the same computer. A singleapplication may be distributed to run on multiple computers, withdifferent process being run the same or different processes run on moreparts of a single application may run on different computers, or ondifferent computers in communication with each other. Furthermore, anapplication program can have different parts executing on differentcomputers in communication with each other. Different instances of thesame application running on the same or on different computers,different applications running on the same computer, and differentapplications running on the same computer or on different computers, mayexchange messages.

For purposes of the following description, an instance of an applicationprogram being executed by one or more computers will be referred to as a“workload.” A workload is comprised of one or more workload units. Eachworkload unit is hosted in one computer, called a node, and executes aset of instructions (a program) that implements at least part of thelogic for the application. Thus, a workload can be distributed overmultiple nodes by having different workload units running on differentnodes, with each workload unit running on a single node.

Workload units can be made capable of communicating with other workloadunits in the same workload or in another workload by exchanging messagesover a network. Generally, these messages are contained within packetstransmitted on a network or set of interconnected networks usingInternet Protocol (IP). An IP network can be a local network, awide-area network, or two or more interconnected networks, including,for example, the Internet. A workload unit can offer one or moreservices that can receive messages from remote clients using apre-defined protocol. An example this product is HTTP, but it could beany number of other protocols. A person (a “user”) interacting with anapplication (a web browser, for example) running on a computer can usethe accessed application to send messages to, and to receive messagesfrom, other workload units. A workload unit can offer one or moreservices that can receive messages from remote clients using apre-defined protocol such as for example http.

In this example, there are two application workloads, workload W1 andworkload W2; and two users, U1 and U2. Workload W1 has three workloadunits, W1.1, W1.2 and W1.3; and workload W2 has one workload unit, W2.1.User U1 can access workload units from device 1 using an accessapplication workload unit A1. User U2 can access workloads units fromdevice 2 using an access application workload unit A2. The dotted arrowsshow the application communication requirements. Workload units W1.1 andW1.3 need to use a service offered by workload unit 1.2. Workload unit2.1 need to use a service offered by workload unit 1.3. Both users U1and U2 should be allowed to access a service offered by workload W1.1,and User U2 should also be allowed to access a service offered byworkload W2.1.

FIG. 4 is a simplified example of an application level security policyfor the computer infrastructure of FIG. 3. It is presented in the formof table. However, it can be stored in any number of forms in adatabase. When given a set of users U1 and U2 from the example of FIG. 3and workload units W1.1, W.2, W.1.3 and W2.1, an application levelsecurity policy specification defines a set of rules, R1 to R6, thatspecify which workloads and users may communicate with each other andthe type of service that can be provided through that communication.These rules enable the communication pattern between a “client” of agiven service (S1, S2, S3 and S4 are for examples that are given) and a“provider” of that service required for correct operation of theapplications and also to enable users to access the workload units forwhich they are authorized to use.

Each rule specifies a service, a provider that offers the service, and aclient that accesses the service. A rule can specify different possibleactions. Two basic types of actions, “allow” or “block”, are assumed,but any type of action that can be enforced by underlying network policyenforcement mechanisms can be used. An “allow” action indicates that theclient is authorized to access the service. A “block” rule indicatesthat the client is not authorized to access the service. In addition tothe rules, an application security level policy may also specify adefault action that should apply to any communication not explicitlydefined in any of the policy rules.

The following is a more description of various types applicationsecurity policies that may be used with the system and processesdescribed below. This list of security policy types is not intended tobe exhaustive.

A white list communication policy explicitly defines the communicationallowed between logical groups, particularly a source logical group anda destination logical group. The policy will specify, in addition to thelogical groups, a network protocol (TCP, UDP, ICMP are well knownexamples of network protocols, but there are many others) and portnumber (for protocols that support port number) that is allowed betweenthe two groups. Only explicitly defined communication is allowed. If acommunication is not defined in the policy, then it is not allowed.White list communication policies (those including a rule with an“allow” action) are used by certain of the processes described herein toconfigure and check security groups and/or host firewall mechanisms.These network security mechanisms are typically configured to deny allcommunication that is not covered by the explicit rules defined by thepolicies.

Black list communication policies (those including a rule with a “block”action) define communication that is explicitly not allowed between asource and a destination logical group. This type of policy can beenforced by disabling logical group membership of resources that have“white list communication” policies that violate the black listcommunication policy.

Constraint policies define combinations of logical group membership thatare not allowed. The constraints are defined as logical expressions with“and”, “or” and “not” operators on logical group membership. Forexample, the expression “LG1 and (LG2 or LG3)” define that a resourcecannot be a member of logical group LG1 and at the same time be a memberof either logical group LG2 or logical group LG3. This type of policy isalso enforced by disabling membership on security group that violatesthe constraints.

Security service requirement policy can be used to specify thatresources in one logical group have a specific security service appliedto it. For example, a policy can define that resources have theirnetwork traffic processed by a “Web Access Firewall” or an “IntrusionPrevention System” appliance.

FIG. 5 schematically illustrates or represents the processingarchitecture on an aspect of the contextual security platform forconfiguring different types of network security mechanisms (mx.y) forenforcing rules on network traffic at different points of the networkinfrastructure based on application level security policies. The policymanager provides a multi-layer in depth defense system and configuremultiple enforcement mechanisms in a coordinated way. By configuringmultiple mechanisms, the policy manager combines their differentcapabilities and features and offer a better effective global securitythan what each individual mechanism can offer in isolation. Using adatabase of the system model that describes the workloads, users,compute environments and available network security enforcementmechanisms, the contextual security platform automatically deploysnetwork level security rules at appropriate enforcement points toprotect the workloads.

Shown is this example is on premise data center 502 of an organizationor enterprise, representative of a physical network, and a cloud serviceprovider environment 504 that provides virtualized infrastructureresources for use by the organization as part of its computer network.While FIG. 5 shows only two environments, any number of environments canbe controlled by the contextual security platform.

In the on-premise data center 502, there are two hardware servercomputers 506 and 508, that are intended only to be representative of alarge number of servers that might otherwise be hosted in thedatacenter. Information about the infrastructure resources identified inthe FIG., such as applications (labelled “A”), servers (labelled“server”), nodes (“node”), security mechanisms (labelled “m”), andworkloads (labelled “WU”) are stored in infrastructure resourceinformation database 210. This information about the infrastructureconstitutes a model of the computer network—a “system model.” Physicalor hardware server computer 506, which is labelled server1.1, hosts twological or virtual computer instances (virtual machines, for example)510 and 512, labelled nodes 1.1 and 1.2 in the system model,respectively. Nodes can be bare metal servers or virtual machines orcontainers hosted on a virtual environment such as a hypervisor or anoperating system with an application container technology. Node 1.1 isexecuting one workload unit of an application and node 1.2 host twoworkload units of the same or a different application. A workload unit(WU) execute application logic and are hosted in a compute node.Hardware server computer 508 is a “bare metal” server that hosts a WUunit directly. It is therefore labelled as node 1.3 in the system model.Each of the nodes includes a native security mechanism, labeled M.1,m1.2, and m1.3 in the system model, respectively and referenced withnumbers 514, 516 and 518. Similarly, hardware server computer 506, eventhough it is not labelled as a node, may also have a security mechanism,labelled m1.4 in the system model.

Nodes can also be virtual instances hosted in a public or private cloud,examples of which are service such as Amazon AWS, Microsoft Azure Cloud,and OpenStack. These cloud providers can provide isolated networkdomains (for example Amazon EC2 “virtual private cloud) which can beisolated or connected with other VPCs or datacenter networks usingvirtual routers. A VPC allows creation a virtual network including IPaddress range selection, creation of subnets, and configuration of routetables and network gateways and provisioning of virtual resources fromservice provider to that domain. In the simplified, representativeexample of a cloud services environment illustrated in the FIG. 5, thereare three nodes 520, 522, and 524, which are labeled in the systemmodel, respectively, as nodes 2.1, 2.2 and 2.3, each with one workloadunit. Nodes 520 and 522 are hosted on a virtual private cloud (VPC) 526labelled in the system model as VPC2.1 Node 528 is hosted on a secondvirtual private cloud 504 (not necessarily from the same serviceprovider as VPC 526). Nodes 520, 522 and 524 each has a securitymechanism 530, 532 and 534, respectively. They are labelled, 2.1, m3.2and, 2.3 in the system model. Each VPC also has multiple securitymechanisms. VPC 526 has security mechanisms 536 and 538, labelled m2.4and m2.6. VPC 528 has security mechanisms 542, labelled m2.5, andsecurity mechanism 544, labelled m2.7.

The contextual security platform provides a multi-layer in depth defensesystem and configure multiple enforcement mechanisms in a coordinatedway. By configuring multiple mechanisms, the contextual securityplatform combines the different capabilities and features of the nativesecurity mechanisms to offer a better and more effective global securitythan what each individual mechanism can offer in isolation.

A network security enforcement mechanism intercepts network traffic at agiven point in the communication path and checks the traffic against aset of network security rules. A network security rule is usuallyspecified by a set of matching conditions and an action. Every packetprocessed by the enforcement mechanism is checked against all thesecurity rules. If the conditions specified in a rule is satisfied bythe packet, the rule is said to match the packet. In general, more thanone rule can match a packet. In this case a priority mechanism is usedto select one of the matching rules and the action specified by thehigher priority rule is applied to the packet. Many different types ofactions can be specified in a rule, but for the purpose of the followingdescription, two common actions, allow and block, are considered. An“allow” rule allows the packet to continue on its path to itsdestination and a “block” rule discards the packet. Matching conditionsof a rule can specify a set of conditions that common fields in anetwork packet should satisfy. These conditions may specify a value, arange of values, or a prefix that a packet field must satisfy. Packetfields commonly used in network security rules include:

The IP protocol number in the packet IP header field;

The destination IP address in the packet IP header field;

The source IP address in the packet IP header field;

The destination port number in the TCP or UDP header if the IP protocolis TCP or UDP; and

The source port number in the TCP or UDP header if the IP protocol isTCP or UDP.

Some network security mechanisms also use other packet fields such aslayer2 MAC addresses, frame type, VLAN id, etc. They can also usemetadata information that is not present in the packet data but can beextracted from the network processing environment such as for examplethe port in which the packet was received on a multiport device such asa network switch.

The contextual security platform maps application level security rulesto network security rules of one or more network security mechanismsbased on the type of application level rules, the properties of thecomputer environments hosting the application workloads and thecapabilities of the available network security enforcement mechanisms.

The mapping relies on the database of the system model 210 thatdescribes the workloads, users, compute environments and availablenetwork security enforcement mechanisms. The contextual securityplatform deploys the network security rules at appropriate enforcementpoints to protect the workload units in the compute environments.

The network policy enforcement mechanisms can control network traffic atdifferent enforcement points. Host based security mechanisms (e.g. m1.1,m1.2, m1.3, m2.1, m2.2 to m2.3) are implemented by operating systemmechanisms in the nodes that host the workload units. As they areco-located with workload units they can provide isolation among workloadunits hosted in the same node. On the other hand, they share the samesoftware domain as the workload units and are more vulnerable tosecurity threats that compromise the workload units or other softwarecomponents in the nodes.

An environment managed by the contextual security platform can hostnodes with different operating systems that provide different networksecurity mechanisms. For example, Linux offers IPtables and MicrosoftWindows offers Windows Firewall as network policy enforcementmechanisms. When nodes are virtual machines or containers, their trafficcan be enforced by mechanisms running in the hypervisor or operatingsystem hosting the virtual nodes (for example security mechanism 1.4).Examples of these mechanism include VMWare NSX Distributed Firewall andalso Windows Firewall or Linux IP tables when these operating systemsare used as hypervisors or containers hosts.

The contextual security platform can also configure firewall mechanismsimplemented in network devices such as routers, switches and firewalls,an example of which is security mechanism m1.5. These network mechanismscould be, for example, configured using device specific or proprietaryAPIs offered by the manufacturer or using software-defined networks APIssuch as Openflow. When using compute environments in public or privateclouds, the contextual security platform uses the cloud infrastructureprovider APIs, if available, to configure network security mechanismsoffered by the cloud infrastructure service providers (for examplesecurity mechanisms m2.4-m2.7). Some cloud providers offer more than onenetwork security mechanism. For example, Amazon AWS offer securitygroups that can enforce security rules for individual virtual machineinstances, and also offer network access control lists (ACL) which canenforce security rules for traffic entering or exiting subnets.

The contextual security platform can offer APIs that can be used byexternal systems, represented by block 546 in FIG. 5 and block 218 inFIG. 1, as well as user interfaces, as represented by block 216 in FIG.1, to configure the system model and define application level policies.For example, an external software deployment system can use thecontextual security platform API to inform in which node, server, VPC orcompute environment workloads are deployed. The contextual securityplatform can also interact with user management systems like LDAP orActive Directory to obtain user authentication and authorization.

FIG. 6 describes an exemplary process 600 of mapping an applicationlevel security policy rule to network level security policy rules thatmay be used by the contextual security platform. In this example, theapplication level security rules specify a service, a client of thatservice, and a provider of that service.

At decision step 602, the process determines whether a client of anapplication policy rule 601 is a managed workload unit. If it is, itidentifies at step 604 the computing environment and the node hostingthe workload unit using the system model that is stored part of themanaged network's infrastructure resource information database 210.Then, at step 606, based on at least the computing environment and node,as well as, if desired, configuration preferences, the process selectsautomatically, using the system model, one or more security mechanismsto enforce egress rules for the client. At step 608, the parameters forat least one egress rule associate with the service and provider theservice that is the subject of the application policy rule is computed.At step 610 the at least one egress rule is created and each of the oneor more selected network security mechanisms is configured to enforcethe at least one egress rule. The process then proceeds to step 612.

If, at step 602, the process determines that the client of theapplication policy rule is not a managed workload unit, it proceeds tostep 612.

At step 612, the process automatically determines using the data orinformation stored in infrastructure resource information database 210whether the provider of the service that is the subject of theapplication policy rule is a managed workload. If it is not a managedworkload, the process ends. Otherwise, at step 614, the processautomatically identifies the computing environment and the node hostingthe provider workload unit. Then, at step 616, based on the computingenvironment, the node, and, if desired, the configuration preferences,the process automatically selects one or more security mechanisms toenforce one more ingress rules for this provider. Then at step 618, theprocess computes the parameters for the at least one ingress rule.Finally, at step 620, the process automatically creates the at least oneingress rule and configures each of the one or more selected networksecurity mechanisms to enforce the at least one ingress rule.

Each workload unit can provide one or more services to a set of clients.The set of application security rules that specify the clients andservices that can be accessed in a given workload unit define the set ofingress security rules that need to be enforced for that workload unit.And the set of application security rules that specify the providers andservices that a workload unit can access define the set of egresssecurity rules that need to be enforced for that workload unit. Thus, agiven application level security rule can generate two network policyrules, an ingress network security rule for the service provider and anegress network security rule for the client of the service.

According to another process of the contextual service platform, theinfrastructure of a computing system is automatically discovered. Thismay be done in one of two ways or in both ways, depending on the natureof the network resources.

In the first way, the process accesses over the network an applicationprogramming interface (API) offered by each of public and private cloudservice provider that host a workload on a virtual server, container(for example those offered by the Docker and Kubernetes cloud services)or other virtual resource. Examples of virtual network resources includeload balancers, routers, networks, subnets, database as a service, andweb services. For traditional physical resources that do not have anAPI, resources are discovered using software agents installed oncomputers that communication the central CSP platform using TCPconnections in addition to traditional physical resources, agents canalso be used to discover virtual or cloud resources when APIs are notavailable or when the driver plugin for that API has not been developedyet.

There are various types of security mechanisms that are available incloud and physical computing infrastructures with which the contextualsecurity platform may be programmed to interact. This list is notintended to be exhaustive of all of the possible security mechanismsthat exist or that might be developed.

“Security groups” are available in most cloud infrastructure providers,including AWS, Azure, GCP and OpenStack (see below). A security groupdefine a set of rules that control inbound and outbound datacommunications to and from an infrastructure resource. The standardprotocol currently used for sending data across interconnected computernetworks is the Internet Protocol (IP), which sends data (such asmessages or any other type of data) in packets between hosts usingdatagrams that can be routed through a computer network and betweennetworks with regard to the underlying physical media. Therefore, thefollowing examples parameters are given in terms of packet switchednetworks:

a) IP address or IP address of the packets, which indicate the sourceand destination hosts for the packets, can be used to specify with whomthe resource can communicate by specifying the address or range ofaddresses to which data packets can be sent (for outbound rules) or fromwhich the resource is permitted to receive data packets (for inboundrules).

b) One or more allowed, higher level communication protocols, such usTransmission Control Protocol (TCP), User Datagram Protocol (UDP), andInternet Control Messaging Protocol (ICMP), that is used to control thedata flow or flow of packets between the resource and another host for aparticular communication session.

c) The destination port, which is usually used to define the type ofservice for which the communication is taking place. For example, port80 is used for web http request, port 443, for secure http requests.

However, the particular parameters types of parameters may changedepending on the type of networking protocols in use. Security groupsare configured based on white list communication policies. To configuresecurity groups the system maps logical objects to resources usinglogical groups and then maps the resources to their IP addresses usingdiscovered resource properties.

“Host firewalls” are software firewalls implemented in host operatingsystems that control inbound and outbound traffic to the host. Thesefirewalls are configured in the same way as security group using “Whitelist communication policies. “Web application firewalls” (WAF) is anapplication level firewall that filters, monitors, and blocks HTTPtraffic to and from a web application. An “Intrusion Prevention System”(IPS) is a computer network service that examine network packets contentto detect and prevent vulnerability exploits. Usually offered in cloudproviders as an appliance which process network traffic for resources.Next generation Firewalls, an example of which is the Palo Alto NetworksFirewall), combine traditional firewall capabilities with advancedfiltering capabilities that can operate at application level using deeppacket inspection techniques. Data encryption mechanisms can be used toencrypt data at rest or when it is being communicated through thecomputer network. Finally, “generic security” is any other type ofsecurity service offered by an infrastructure service provider. Forexample, Amazon Web Services offers a security service called“Inspector,” that inspects virtual machines and access applications forvulnerabilities and deviations from best practices.

Different network security enforcement mechanisms offer differentcapabilities. One of the criteria used so select enforcement mechanismsby the following process are the capabilities of the securityenforcement mechanisms. Briefly discussed below are some of the one ormore capabilities that may be taken into account by the process:

Supported actions. Some enforcement mechanisms may not support bothtypes of rule actions. For example, Amazon AWS security group onlysupport “allow” actions, and do not support “block” actions

Degree of isolation from workload unit. Enforcement mechanismsimplemented at the operating system level are more susceptible tosecurity threats that exploit vulnerabilities of applications running onthe same operating system. If a threat is able to gain root access in anoperating system it can disable the security rules of the enforcementmechanism. Enforcement mechanisms implemented outside the operatingsystem are in a different security domain and are much less vulnerableto these threats. Among these, enforcement mechanisms implemented inseparate devices, such as network firewall, switches, etc., offer thelowest degree of vulnerability. A mechanism can thus offer one of threepossible degrees of isolation in increasing order of isolation:

1) Same software domain as the workload unit,

2) different software domain,

3) different hardware domain

Notification of discarded packets. Some enforcement mechanisms may beconfigured to generate a notification when a packet is discarded becauseit violates the network security policy. This can be useful fordetecting missing policy rules or for generating alerts of possiblesecurity threats. In general mechanisms implemented in operating systemsand hypervisors can be instrumented to generate these notifications.Network devices such as firewall and cloud network security API'susually do not offer this capability

Support matching condition on application program. Some enforcementmechanisms implemented at the operating systems can support matchingrules that specify a particular application program. This can be usefulto define different security policies for different workload units thatare hosted on the same node.

Maximum rule capacity. Some enforcement mechanisms have a maximum numberof rules that be configured. Mechanisms in public cloud providers areexamples of these mechanisms.

Network coverage. When protecting a given workload unit an enforcementmechanism may not enforce the policy rules in all traffic sent from orto that workload unit. For example, a network switch is not able toenforce the policy rules on network packets sent between two virtualmachines hosted in the same hypervisor, since these packets are notprocessed by the network switch.

Enforcement mechanisms implemented in the operating system have thehighest degree of network coverage. Mechanisms implemented at thehypervisor or offered by cloud providers have the same degree ofcoverage if a workload unit does not share the same node with anotherworkload unit. Otherwise, hypervisor or cloud provider mechanisms cannotenforce policy rules for network traffic between these workload units.Physical network switches have the lowest degree of network coverage asthey do not process packets exchanged between virtual machines hosted inthe same physical server.

Turning now to FIG. 6, steps 602 to 610 are executed if the client ofthe application policy rule is a managed workload unit. These stepsgenerate network egress rules in one or more network policy enforcementmechanisms for the specified client. Steps 612 to 620 are executed ifthe provider of the application policy rule is a managed workload unit.These steps generate network ingress rules in one or more network policyenforcement mechanisms for the specified provider workload unit. Togenerate the egress rules in step 608, the service is mapped to thefollowing possible parameters: 1) a protocol (such as TCP, UDP, ICMP, orany other IP protocol), 2) the IP protocol version (IPV4 or IPV6), and3) a port number used by the service (if supported by the protocol). Theworkload unit provider is mapped to an additional set of parameters thatcan be used by each selected network enforcement mechanism to identifythe destination of the network traffic at the enforcement point. Atypical parameter used to identify the workload unit is its IP address(either an IPV4 or IPV6 address or both). But some mechanisms can useadditional parameters to identify the workload unit. For example,operating systems enforcement mechanisms, such as Linux IP tables orWindows Firewall can use the application executable name or the processname to identify the workload unit. This allows finer control of thenetwork policy rules that can separate network traffic for differentworkload units hosted on the same node (for example, workloads in node1.2 of FIG. 5). Step 608 uses the action specified in the applicationpolicy rule to configure the action of the network security enforcementrule. Similar to step 608, step 618 computes the service and the clientworkload unit parameters to generate the ingress rules, for the providerworkload unit.

The parameters used to configure ingress and egress rules in the networksecurity enforcement mechanism are obtained from the system modeldatabase of the policy manager. The following are a list of some exampleparameters obtained from the system model database:

Protocol and destination port: The protocol and port associated with theservice offered by the provider workload.

Destination IP address (optional for ingress rules): The IP addressassociated with the provider workload unit.

Source IP address (optional for egress rules): The IP address associatedwith the client

Source port: in general, the source port is configured to “any port”.

Process and/or application executable name (optional): The process orapplication executable associated with the provider workload unit, ifused in an ingress rule, or with the client workload unit if used in anegress rule. This parameter only needs to be configured if multipleworkload units are hosted on the same node.

Users that need to access managed workloads units need to beauthenticated. Authentication can be done by the policy manager itselfor it can be done using an external user authentication mechanism suchas LDAP or Active Directory. Once the user is authenticated, the policymanager updates all network security rules generated from allapplication level policy rules defined for that user. When updating thenetwork security rules, the policy manager need the network IP addressassociated with the authenticated user. This IP address can be obtainedusing different mechanisms:

The IP address can be obtained from a request submitted by the user tothe policy manager requesting access to services in one or more workloadunits.

The IP address associated with the user can be configured using thepolicy manager API by the user interface or an external software system.

The IP address can be generated by an agent running in the clientaccording to the mechanism described below

In some network configurations, a user IP address can also be used byother users. This can happen for example if there is a network addresstranslation device between the user access device and the workload unitaccessed by the user. Several users behind the network addresstranslation device, may have their private IP address translated intothe same IP address in the network that host the workload unit. In thisscenario, it may be desirable to use additional mechanisms to identifythe user, instead of relying only on its IP address, such that only theauthorized user is allowed to access the workload unit. An example ofsuch mechanism is the following.

An agent running on the user device authenticates the user with thepolicy manager. The agent monitors network traffic generated by the userand intercept requests to access workload units managed by the policymanager. If the agent detects such an attempt, it forwards a request toaccess the workload unit to the policy manager on behalf of the user.The policy manager checks if the user is authorized to access theworkload unit by checking the set of application level policy rules forthat workload unit. If the user is authorized to access the workloadunit, the policy manager generates and sends to the user agent a uniquesecret key. The policy manager also adds a temporary ingress securityrule for the workload unit authorizing access from the client IPaddress. The user agent sends the secret key on a special network packetto the workload unit that the user is trying to access using the samesource TCP or UDP port. An agent running on the same node as theprovider workload unit, intercepts this packet and forward the key withthe received source TCP or UDP port to the policy manager. The policymanager validates the secret key, and if it is the correct key itreplaces the temporary ingress security rule with another rule thatinclude not only the user IP address but also the source port used bythe user to access the workload unit. With this rule, only theauthorized user is able to access the workload unit. Other users usingthe same IP address will not be able to access the workload unit, sincethe network address translation device will map their connectionrequests to different source ports.

The mechanism described above may allow access from non-authorized usersthat share the same IP address with the authorized user for a shortperiod of time. After the temporary ingress security rule is added, allusers with that IP address are able to send packets to the workloadunit, until the rule is replaced with the rule that include the correctsource port of the authorized user. This can avoided by having the agentrunning on the same node as the workload unit to block all traffic fromthe user IP address (except maybe for traffic from other users alreadyauthorized) until the final ingress rule is created. This allow theagent to receive the special packet with the secret key but prevent anynon-authorized network packet to reach the workload unit. After thepolicy manager configures the ingress network security rule with thecorrect source port, it notifies the workload unit agent to allowtraffic from that IP address again.

The contextual security platform, in one embodiment, configures multiplenetwork security mechanisms in a coordinated way in order to takeadvantage of the combined set of features and properties of all themechanisms. For each application level policy rule, the contextualsecurity platform selects one or multiple network security enforcementmechanism to enforce that application policy rule in a coordinated way.The selection of the mechanisms is based on the required applicationpolicy and desired properties configured in the system.

The flow chart of FIG. 7 illustrates a process 700 for selecting the setof network enforcement mechanisms. Different compute environment canoffer different mechanisms with different capabilities. The set ofavailable mechanisms can be determined by identifying the computeenvironment in which the node hosting the workload unit is located. Notall mechanisms can be used to support a particular application levelsecurity rule. For example, some mechanisms may only support ingressrules but not egress rules (e.g. Network firewalls available in GoogleCompute Engine cloud environment do not support egress rules). Somemechanisms may support only one type of action, allow or block (e.g.Amazon AWS security group do not support “block” action, but only“allow”). The collection of mechanisms that can support the requiredapplication level security rule and offer the best properties areselected as follows.

First, from the set of available mechanisms for the node hosting theworkload unit, only those that can support that type of rule isconsidered. Also, some mechanism may have restrictions on the number ofrules. These steps are represented by blocks 701, 702, and 703. Asindicated by block 704, if any mechanism reaches the maximum number ofrules, it is removed from the list of candidate mechanisms to beselected. Of the remaining mechanisms, the process of FIG. 7 selects onemechanism using one of two possible criteria, as indicated by blocks 705and 706. In one of these criteria, the method selects the mechanism withthe best network coverage. In the other criteria, the method selects themechanism with the best degree of isolation from the workload unit. Theselection of which criteria to use can be done using a systemconfiguration option. If more than one mechanism is selected by theprimary criteria, then the method uses the other criteria to favor oneof the mechanisms. This is represented by blocks 705 and 706. If morethan one mechanism is still selected any one can be chosen. It ispossible that the selected mechanism does not offer all the capabilitiesneeded. For example, as indicated by block 707, if isolation betweenworkload units that share the same node is desired and the workload unitis sharing the node with another workload unit, then a mechanism thatcan identify the application program as a matching condition is added asan additional mechanism if that is not supported by the primarymechanism. Similarly, if the workload unit is configured to generatenotifications when packets are discarded because they violate thenetwork security, then an additional mechanism that supports thiscapability is added, as indicated by block 708. After the selectedenforcement mechanisms are identified they are all configured with thesame security rule (except for maybe rule conditions not supported bythe mechanism), as indicated by block 709. This coordinatedconfiguration of multiple network security mechanisms, allows aneffective global security policy that combine the best features of allmechanisms, providing better security for the application than anyindividual mechanism could do in isolation.

An extension to the selection mechanism described above is to selectmore than one mechanism to enforce the same security rule withredundancy. This way if a mechanism is compromised by a securityvulnerability and stops enforcing the desired security rule, the othermechanism would continue enforcing it. In this case a configurationoption would specify a desired level of redundancy (number of mechanismsenforcing the same rule) and the mechanism would try to select thatnumber of mechanisms if possible using the same criteria described usedto select the first mechanism.

The processes of the contextual security platform discover theinfrastructure resources of the computer network being managed, and thenmap the logical objects in the application security policies to thecomputer network infrastructure resources that have been discovered sothat native security mechanisms applied to infrastructure resources canimplement the application level security policies. This mapping isaccomplished, in a preferred embodiment, by associating with applicationsecurity policy logical objects logical groups (described below) andinfrastructure resources tags that comprise key/value pairs.

Security policies are specified using logical objects such asapplication name, computer service, data (such as an HR database), orsecurity posture, examples of which include PCI compliance and HIPPAcompliance. For example, a security policy can define if an applicationcan access a specific database or computer service, or if theapplication needs to be compliant with a given security posture such asPCI.

The processes of the contextual security platform associateinfrastructure resources with logical objects using attributes.Attributes are <key, value> pairs associated with resources that definea logical property of the resource. For example, if a server is used tohost an application name “app1” it would have an attribute withkey=“application” and value=“app1”.

Logical objects that are used to define application security policiesare represented by logical groups. For example, a logical group can beused to represent an application, an application component (e.g. the webtier in a 3-tier application), a group of applications (e.g. all HRapplications), a security posture (e.g. all PCI compliant applications),a data set (e.g. a database with clients' personal info), etc.

For example, if a server is used to host an application “app1” it couldhave an attribute with key=“application” and value=“app1”. Each logicalgroup defines a set of “selection” attributes that are used to selectinfrastructure resources to be members of the logical group. Forexample, the attribute <“application”, “app1”> can be the “selection”attribute for the logical group used to represent application “app1”. Inthis case, all resources that have this attribute become members of thislogical group.

Infrastructure resources such as servers, disk volumes, and many othertypes of resources found in a computer network are also mapped tological groups using attributes that are <key, value> pairs associatedwith infrastructure resources.

Attributes can be assigned to infrastructure resources using differentmechanisms:

a) Infrastructure tags. Cloud infrastructure service providers such asAWS, Azure, GCP and OpenStack allow used defined tags to be associatedwith infrastructure resources. These tags are read using the API of theservice provider during the process of discovering infrastructureresources and used to automatically map discovered infrastructureresources to logical groups. This allows automatic deployment ofpolicies when new resources are discovered.

b) Resource property. An attribute can be assigned to resource based onany property of that resource that can be read using the infrastructureprovider API. For example, an attribute <“subnet”, “abc”> can beassociated with resources using the “abc” subnet

c) User input. User can manually assign attributes for discoveredresources using CSP console or UI.

d) Logical group assigned. A logical group can also define “assign”attributes in addition to the “selection” attributes. “Assign”attributes are automatically added to resources that are selected asmember of the logical group. For example, assume that a logical groupPCI defines a selection attribute <“compliance”, “pci”> to selectsresources that should satisfy the PCI security posture. Anding an APP1logical group defines a selection attribute <“application”, “app1”> toselect resources hosting application app1. Now assume application app1is a PCI compliant application. In this case, logical group APP1 candefine an “assign” attribute <“compliance”, “pci”> which isautomatically assigned to all resources of application “app1”. Thisensures that all resources for application app1 are assigned policiesdefined for PCI logical group.

In addition to “explicit” logical group defined with “selection”attributes or by manually selecting resources, “implicit” logical groupscan be automatically created to represent any groups that may alreadyexist in cloud providers. These groups are created based on propertiesassigned to discovered infrastructure resources. An important propertyof these logical groups is that membership cannot be configured orchanged as it is based on existing resource properties. Example ofimplicit groups include:

a) Amazon AWS resource properties: VPC, region availability zone,account, network, and subnet, for example.

b) Microsoft Azure resource properties: Resource Group, region, Virtualnetwork, and account, for example.

c) OpenStack resource properties: project, region, networks, and subnetare examples.

Incoming and outgoing network traffic flows for infrastructure resourcesare captured and mapped to logical groups containing the monitoredinfrastructure information. This allows the system to identify andexpose the communication requirements needed for the logical objectsdefined by the logical groups. Raw network traffic with low level rawnetwork data such as IP addresses are therefore mapped to logicalobjects, such as application, application component, security posture,and also infrastructure groups such as AWS VPCs, OpenStack Projects,etc., which are high level objects used by policies.

This capability allows the system to extract real-time communicationrequirements and define micro-segmentation policies that restrictcommunication among applications and generic logical groups to thestrict necessary to support the applications. These policies can blockall communication that is not needed to support the system applicationand services and prevent lateral movement of any malware that is able tobreak into a specific application, preventing the malware to propagateto other components.

In addition, by mapping communicating endpoints to logical groups, thesystem can identify any violation in communicating policies betweenlogical groups including explicit and implicit infrastructure groups,inside a single cloud provider or across different cloud providers.

For example, if a policy prevents resources in a given AWS VPC tocommunicate with resources in a given OpenStack Project, and if theendpoints of a flow is mapped to that VPC and Project, then a policyviolation is detected.

In addition to detecting active communication to and from monitoredresources, the system also detects attempts of communication that areblocked by security enforcement mechanisms (flow violations.) Thisallows the system to detect and generate alerts when components try toviolate communication policies which could indicate a malware activity.These are called flow attempted violations or simply flow violations.

Using infrastructure provider APIs or agents, the system monitors theconfiguration of the existing security mechanisms and verify if theycomply with the defined security policies, generating alerts if anyviolation is detected.

Infrastructure providers offers multiple types of security mechanisms.These mechanisms are automatically configured to enforce the policiesdefined in the system. For example, communication policies that defineallowed communication between logical groups are uses to create securityrules in AWS Security groups, OpenStack Security groups, Azure SecurityGroups, Host Firewalls, etc. These rules are deployed to theinfrastructure resources using infrastructure provider APIs or agents.

The configuration of security mechanisms is optional. The contextualsecurity platform could just check if the configuration of aninfrastructure security mechanism is compliant with policies or not. Ina preferred embodiment, the contextual security platform may have aconfiguration mode—either active and passive—that can be set for eachsecurity mechanisms. For example, the configuration may be set toactively configure security groups rules, but only monitor ifapplications are properly configured to use AWS WAF security mechanismbased on policies.

The processes of the contextual security platform may also automaticallychange the policies associated with individual infrastructure resourcesbased on alert events or user input. This is accomplished using a“policy state” associated with resources. Usually a default “normal”state is associated with discovered resources. Logical groups areusually defined to select only resources in the “normal” state. However,other policy state values can be defined for resources, and otherlogical groups defined to select resources in these other state values.When a resource changes its state the set of logical groups that theresource belongs change as well. Only logical groups defined for that“policy state” are applied to the resource. This allow the system tochange the set of policies applied to resource when its state changes.

A state can be automatically changed for a resource based on alertevents. For example, the system can change the “policy state” of aresource from “normal” to “quarantine” when the processes of thecontextual security platform detect a violation of a security policy, orperhaps repeated attempts to violate a security policy. For example, ifthe processes of the contextual security platform detect more than 10data flow violations in a period of 5 minutes, a process within thecontextual security platform would cause the resource to be removed fromall logical groups defined for “normal” policy state and possibly addthe resource to logical groups defined for the “quarantine” state basedon its attribute and the “selection” attributes of the logical groups.

A logical group can define more than one “policy state” to selectresources. In this case resources in either state can be members of thelogical group.

Application security policies can be used to configure mechanisms acrossdifferent infrastructure providers. This allow the same policy to beused in different providers, enabling applications to be moved acrossproviders and security mechanisms automatically deployed and configuredbased on the existing policy definition. Thus, there is no need tomanually reconfigure and change security mechanisms because, forexample, an IP address changes. A process within the contextual securityplatform will automatically detect and update the configurationautomatically based on higher level policies.

Furthermore, the processes of the contextual security platform may alsocontinuously monitor each security mechanism to make sure that it iscompliant with application level security policies and automaticallyreverse any changes to the security mechanism done outside of thecontextual security platform system, security configurations can,therefore, be locked using the contextual security platform becausesecurity policies are defined in software and used to automaticallyconfigure security mechanisms, using heterogeneous APIs of differentinfrastructure providers.

FIG. 8 represents an exemplary process 800 of discovering and applyingtags for resources.

Prior to the execution of the illustrated process, a user configures thecontextual security platform to access an infrastructure serviceprovider account by entering account credentials to allow access to theapplication programming interface of the infrastructure provider API.

As represented by steps 802 to 808, the contextual security platformcontinuously discovers infrastructure resources. To do this, thecontextual security platform periodically, in a configurable timeinterval, queries infrastructure provider APIs (for all configurableaccounts) and retrieves a list of existing resources with theirproperties. The contextual security platform then automatically updatesinfrastructure information database 210 (FIG. 2) with this information,adding new resources and updating entries for existing resources whenvalues of properties change or resources are deleted. As indicated bystep 802, the process of FIG. 8 handles a discovery of a new resource ora property value or tag value change for particular resource. Theresource provider for that resource is obtained at step 804, and a listof properties for that provider that are configured to be used asattributes for that provider is obtained at state step 806. Thisinformation is stored by the infrastructure resource informationdatabase 210 or elsewhere. As indicated by step 808, the process addstags to the infrastructure information database for that resource anattribute for each property in the property list, using the key definedin the property list for each property, and assigns to that key thevalue for the property for the resource that is obtained from theservice provider.

If tags applied by the service provider are to be used by default, asindicated by step 810, steps 812 to 818 are performed. The contextualsecurity platform can be configured to indicate for each serviceprovider whether or not to use by default the tags from that serviceprovider. This configuration information can be stored, for example, inthe infrastructure resource information database 210, or elsewhere.Furthermore, certain tags from the service provider can be ignored, asindicated by step 814. Again, this information can be stored in theinfrastructure resource information database 210. As indicated by steps812 and 818, a loop is performed for each tag from the service provider,which checks at step 814 whether or not the tag is to be ignored andthen creates at step 816 an attribute for that resource using the keyand value of the tag read from the API of the service provider.

If provider tags are not used by default, the process, as indicated byblocks 820 and 826, performs a loop for each tag associated with theresource read from the infrastructure service provider. Whether the tagis part of a list of attribute tags to be used for that provider ischecked at step 822. This list can be stored in infrastructureinformation database 210. If it is, an attribute is created at step 824in the infrastructure information database for that resource with thekey and value that is read from the infrastructure service provider.Otherwise, no attribute is created.

As previously mentioned, users access the contextual security platformthrough an API and/or a user interface and define security policies andlogical groups. Users also configure the selection criteria of resourcemembership in each logical group. The contextual security platformcontinuously updates the list of members in each defined logical group.Resources are added or removed when new resources are discovered or whentheir properties change (for properties used in logical groupmembership).

Using the list of defined policies and logical groups with their currentlist of member resources, the contextual security platform computes thedesired configuration of the security mechanisms required by thepolicies. The contextual security platform computes which resources needto have native security mechanisms based on resources selected asmembers of logical groups. The type of security mechanisms and theirconfiguration is computed based on the policies defined for the logicalgroups and the properties of the resources associated with logicalgroups. For example, if a security group is configured to enforce a“white list communication policy,” the IP address of a resource is usedto configure security group with allowed traffic based on which remoteresource a given resource is allowed to communicate to and from.

As previously mentioned, the contextual security platform can operate inactive or passive mode for each native security mechanism. In activemode the contextual security platform uses the provider API to configurethe security mechanism to match the desired state. In passive mode thecontextual security platform just reads the configuration from theprovider and check if it matches the desired configuration, generatingalerts if not.

The contextual security platform continuously monitors the state of thenative security mechanisms using the provider APIs. If the state divergealerts are regenerated and based on system configuration, it changesback the security mechanism to match the desired state, bringing thecontextual security platform back to be compliant with policies.

Using a cloud service provider API (when available) or agents, thecontextual security platform collects data flow information for alldiscovered resources and store them in a database. Data flow informationthat is received may comprise, for example, a TCP or UDP connectionbetween two IP addresses, specifying a port. As network flows arecollected the processes of the contextual security platformautomatically tag each data flow with identifiers for both endpoints orresources that are communicating in that flow. This is automaticallydone by the processes of the contextual security platform using the IPaddress observed in the raw flows and mapping it to the IP addressesassociated with resources that were previously discovered by thecontextual security platform. This allows the flows to also beassociated with all logical groups for which the resources are members,including explicit logical groups and implicit groups based oninfrastructure properties. These flows are then stored in a databasewith the contextual information of resources and logical groups(contextual flows).

Data flows with context information can be graphically visualized in theUI or accessed through the API, exposing current and historicalcommunication among any arbitrary group of resources and logical groups.This visualization exposes the required communication for theapplications and services running in the environment. This is usefulboth for debugging applications and network connectivity, but also fordefining communication policies.

Based on flow information observed in a user selected time period, thecontextual security platform automatically computes “white listcommunication policies” needed for a group of selected resources orlogical groups. Policies that allow only the communication defined bythe observed flows are created but no other one. Optionally the user hasthe option to extend the policy to include additional protocols, ports,resources or logical groups.

To summarize, depending on which of the processes described above areimplemented, a contextual security platform in an exemplary embodimentcan provide one or more of the following advantages:

Continuous discovery of all public/private cloud native infrastructureobjects.

Continuous discovery virtualized and bare metal servers, includingworkloads, services, existing security controls, and data flows.

Creation of visual, searchable maps are created in a user interface thatare updated minute by minute.

Auto-provisioning of native controls based on discovered data flows,tags, attributes and/or infrastructure memberships.

Automating of granular micro-segmentation across providers for superiorsecurity.

Automatically calculating and adjusting the necessary security policychanges as workloads spin up, down or even move cloud service providers.

Monitoring real-time data flows between workloads and comparing todeployed security policies for compliance.

Monitoring the amount of data transferred between the workloads todetect illegal activities.

Generating alerts on any violations and blocks them and can quarantineoffending workload.

Monitoring of native enforcement points. Any accidental or maliciouschanges to native controls are immediately identified and rolled back.

Generation of real-time maps that can be filtered for risk andcompliance to security policies.

Automating control of different polices across development, test andproduction.

Detecting of unauthorized modifications to security configurations.

Separating of duties between development/operations and Security.

Approving the use of protected tags.

Continuous visualization of changing cloud infrastructure to identifybusiness changes and potential risks.

Continuous monitoring of infrastructure, data flows and securitypolicies to identify threats to the attack surface.

Automatic generation of real-time alerts in response to detection ofrisks and threats that could compromise deployments.

Corrective actions to block, quarantine or rollback threats.

Continuous discovery across public and private cloud providers toautomatically map and visualize native infrastructure resources in justminutes.

Making visible pervasively VMs, containers, micro-services, securitypolicies and associated real-time network data flows.

Analysis of real-time network flows, security controls andinfrastructure changes to ensure policies are intact, compliant andprotecting the environment.

Continuous inventorying of all native infrastructure objects of thespecific cloud provider and visually maps them, including, for example,AWS Regions, VPCs, Containers, Virtual Machines, Services, existingSecurity Groups, real-time network data flows and more.

Updating of discovery maps, minute by minute as the environment changes,such as when computing resources spin up or down, including building andre-building a real-time map of the infrastructure and associated dataflows.

Generating visualizations of the entire hybrid/multi-cloudenvironment—not just cloud resources, but virtualized and bare metalenvironments as well.

Building of interactive, visual maps that are interactive and users canfilter, zoom and search.

Building of maps that visually identify malicious and non-compliantactivity in real-time.

Because the cloud-native security controls are outside the workload, thecontrols will remain in effect even if the workload is suddenlycompromised by malware. By comparison, host-based controls reside insidethe attack zone. Furthermore, numerous cloud services (e.g. RDS, Lambda,NoSql. and others) require the use of native controls for access. Thus,the ability or capability to manage and enforce native controls can bedesirable. Leveraging these native controls (e.g. AWS and OpenStackSecurity Groups, Azure Network Security Groups, etc.) results inworkloads that are better protected than those in traditional datacenters. Cloud-native controls coupled with automation, allow forsegmentation and isolation based on infrastructure, applications,services and more, protecting against both the North/South and theEast/West threat. Micro-Segmentation, which utilizes whitelisting(allowing only the absolute minimum connectivity), can be an easy andeffective protection for workloads from attackers. Because workloadsspin up and down quickly (sometimes without intervention of IT team),automation can provide important benefits and advantages to securingapplications on a computer network.

By reducing human intervention during the secure development andmanagement of cloud workloads, security controls can be automaticallyprovisioned and overall security improved. High levels of automationthroughout the development/production lifecycle can significantly reducethe chance of misconfiguration, mismanagement and mistakes.

Cloud providers may implicitly group workloads into VPC's (AWS),resource groups (Azure), projects (OpenStack). Thus, a workload'sinfrastructure membership can be used to define an application securitypolicy. As new workloads spin up, they can automatically inheritpolicies associated with their membership within the cloudinfrastructure by having the contextual security platform assignpolicies for members of that infrastructure.

Explicitly defined workload attributes (tags or labels) can representlogical membership for which security policies can be automaticallyapplied. Tags can be used to represent where a workload is running(development, staging, production, etc.) Security policies can beapplied to security mechanisms to automatically enforce the requiredenvironmental separation.

Workloads can carry additional tags representing sensitivity drivingsubsequent security policy (such as HIPPA or PCI tags). Tags can also beused to automate micro-segmentation of workloads into applications,services or micro-services. Application developers can assign “tags” andattributes as part of their development/orchestration process. Securityteams should control the associated policies for those tags.

Security Teams/Risk Teams can deploy monitoring and visibility solutionsin order to identify potential threats quickly while also confirmingcompliance to policies. 3rd party automation can also be used to providedetailed visibility into real-time state and status of the cloudinfrastructure. Allowing for or supporting use of visualization/loggingcan include insight into real-time data flows, workloads, applications,services, containers and more. Continuous monitoring can compareworkload data flows to actual policies to alert on malicious activity,and continuously watch the cloud native enforcement points to make surethey are not altered and are in compliance with intended policies

Multi-Tenant Exemplary Embodiment

Referring now to FIGS. 9 to 16, a typical use case of any one or more ofthe computer network security processes described above is for managingthe security of computer networks operated by a large enterprise ororganization. Enterprises or other very large organizations often havemany lines of business, departments, projects, and other sets orgroupings of people, responsibilities, and resources. These groupingsmay be given responsibility for operating and managing a subset of theenterprise's computing network infrastructure resources, which mayinclude, for example, computers, network devices, and applications.These smaller groupings of users and resources will be referred togenerically as “groups” or “local organizations” in the followingdescription. Different enterprises or large organizations can use localorganizations in many other different ways, and therefore the followingexamples are not intended to be limiting.

In a computer network security management application having one or morefeatures of the contextual security platform described above inconnection with FIGS. 1 to 8, the computer network security applicationis used to manage global computer network security policies to beenforced across an enterprise, but delegate establishment and deploymentof security policies for a subgroup of computing network infrastructureresources within the enterprise.

The computer network security management application is programmed toallow a user to configure one or more administrators—for example,persons responsible for global security policies for an enterprise—to begiven access to all organizations within the enterprise, including aglobal organization (the entire enterprise), and to assign to thempermission to command the network security application to perform one ormore of the following global tasks: create and delete localorganizations; create global attributes and make them public for globaluse, or export them to specific local organizations that need to usethem; create global policies and make them available across all localorganizations within the global organization through public or exportedattributes; pre-approve usage of public or exported attributes by othersor all local organizations; approve or deny request to usepublic/exported attributes not pre-approved; define global communicationconstraint policies and assign them to local organizations, limiting thepolicies that can be created by the local organizations assigned to aspecific line of business or department; and define attribute constraintrules for global and exported attributes.

The computer network security application may also be set up to allow orauthorize a local organization associated with, for example, aparticular line of business or department, to assign policies tocomputer network resources, such as those that it manages, uses, ordeploys or sets up for its own user. First, the computer networksecurity application may be programmed to allow a local organizationusing the application to select a global policy available to the localorganization, in which case the local organization cannot modify thepolicy and can only use policies that were previously defined and arepre-approved. Second, the computer network security application may alsoallow a local organization to create and deploy, using the application,its own policies, but only if the policies are allowed by constraintsdefined by the global organization and enforced by the application. Byusing such a network security application, each local organization—forexample, each line of business within an organization—may be permittedto quickly define their own policies specific to their applications andenvironment, provided they satisfy global enterprise constraints definedby one or more global security administrators.

The computer network security application thus addresses technicalproblems of securing a large computer network against unauthorizedaccess while allowing multiple groups or local organizations within theenterprise to define security policies for computing network resourcesthat each group or local organization uses. Furthermore, implementingsuch capabilities in computer processes requires solving a number oftechnical problems.

The following are non-limiting examples of implementations of processesin a computer network security application that address one or more ofthe technical problems. The application may comprise a collection ofsoftware programs that are executed on the same or distributed overmultiple computers. The contextual security platform described above inconnection with FIGS. 1 to 8 is one example of such a computer networksecurity application having certain features that can be adapted toimplement these processes. However, not all of the features of theembodiment of the contextual security platform described above arerequired for implementing the processes described in connection withFIGS. 9-16.

Before describing these processes, the following explains certainfeatures implemented for the exemplary embodiment computer networksecurity application for implementing the processes described below tosolve these problems.

Logical Objects

Information about an enterprise's computer infrastructure resources andlogical objects (attributes, logical groups, zones, for example) used bythe computer network security application is stored in memory accessibleby it. This information can be stored in one or more databases and/orfiles stored in a computer memory and accessible by the application. Inthe following description, references to logical objects and resourcesin the context of a description of a computer process, is intended,unless the context indicates otherwise, to refer to computing objectthat is comprised of, at least in part, data stored in memory, which canbe acted on (created, removed, read, and/or written to, for example) bythe computer network security application. A computing object can be adata structure, or a table, column, row, or relationship within adatabase, for example. The following description is not intended to belimited to any particular manner of representing or storing thecomputing objects for use by the computer network security application.Unless the context indicates otherwise, a reference to a “resource” inthe description of the process below is intended to refer to a computingobject that represents computing processes of the actual infrastructureresource, and not the actual infrastructure resource itself.

The following are examples of types of logical objects that processes ofthe computer network security application may create, read and modify:

a. An attribute, which is a property associated with a resource used todeploy a security policy.

b. A network zone, which defines one or more ranges of IP addresses. Arange of IP addresses is a set of continuous IP addresses in the addressspace, usually defined in CIDR format (for example, 10.11.12.0/24, whichinclude all IP addresses between 10.11.12.0 and 10.11.12.255).

c. A logical group, which is group of infrastructure resources used todefine policies.

d. Application, which is a set of logical groups defining the resourcesthat support an application and/or components (tiers) of theapplication.

e. A security policy, examples of which are communication policies,communication constraint policies, and attribute constraint policies.

Each logical object may also have one or more of the followingparameters, which are common across all types of objects: a name uniquein the local organization for that type of object; an identifier thatuniquely identifies the object in the system; and an identifier for thelocal organization that owns the object.

Attributes and Attribute Constraint Policies

The computer network security application delivers or appliescommunication policies to infrastructure resources using attributes. Anattribute is a logical object.

Attributes are, in effect, assigned to infrastructure resources, whichare also represented by computing objects stored in memory, by thecomputer network security application associating in memory theattribute with the resource. References to “resource” in the followingdiscussion will refer, unless the context indicates otherwise, to thecomputing object stored in memory and being acted on by the computernetwork security application, which represents the actual infrastructureresource that exist on the computer network. Once assigned, thisassociation can be used by the computer network security application invarious ways as discussed above in connection with FIGS. 1-8, including,for example, provisioning of security policies to infrastructureresources.

The assignment of the attribute to the resource can be done using one ormore of the following mechanisms or processes.

The first exemplary mechanism uses tags from an infrastructure servicesprovider. Cloud or infrastructure service providers such as AWS, Azure,GCP and OpenStack allow users, though the service's user interface or athird-party interface accessing the service's application programminginterface (API), to define and associate tags with infrastructureresources created using, and hosted by, the service. Using a discoveryprocess, which can be triggered to run automatically, the computernetwork security application reads the infrastructure tags forinfrastructure resources hosted by a cloud service provider bycommunicating with the cloud server provider's API. Based on the tagsreceived by from the cloud service provider, the computer networksecurity application automatically associates corresponding attributesto a resource, if the association is permitted for that resource usingprocesses described below. These processes thus allow automaticdeployment of communication policies for a new resource when the newresource is discovered on a cloud service provider.

A second exemplary mechanism is the computer network securityapplication assigning automatically an attribute to a resource based onany property of that resource that can be read using an infrastructureprovider API. For example, an attribute <“subnet”, “abc”> can beassociated with resources using the “abc” subnet.

A third exemplary mechanism is that a user of the computer networksecurity application can manually assign attributes for resourcesdiscovered by the application using a console or user interface to theapplication.

A final example of such a mechanism is indirect assignment. The computernetwork security application can assign attributes to all members of alogical group. A “select” attribute associated with the logical groupcan be used by the application to select resources as members of thegroup, and an “assign” attribute associated with the logical group canbe used to cause the application to assign automatically to members thatare selected in an attribute. For example, assume that a logical groupPCI defines a selection attribute <“compliance”, “pci”> to selectresources that should satisfy a PCI security posture. Assuming also thatan APP1 logical group defines a selection attribute <“application”,“app1”> to select resources hosting application app1. If applicationapp1 is a PCI compliant application, the logical group APP1 can definean “assign” attribute <“compliance”, “pci”> which is automaticallyassigned to all resources of application “app1”. This ensures that allresources for application app1 are assigned policies defined for PCIlogical group.

In the preferred embodiment of the computer network securityapplication, the application associates an attribute, like other logicalresources, only with one local organization, which becomes, in effect,the “owner” of it. Only resources associated with that localorganization can be assigned that attribute, unless the attribute ismade public or exported. A public attribute (also called globalattribute) is available for association with any one or more of thelocal organizations and can be requested to be assigned toinfrastructure resources associated with any local organization. Thecomputer network security application may also “export”—associate—inresponse to a request, for example, an attribute with another localorganization within the global organization. Export allows the attributeto be requested for use in multiple local organizations but not in alllocal organizations. Public and exported attributes therefore giveaccess to the attribute to local organizations other than the “owner” ofthe attribute.

However, if an organization has access to a global attribute, this maynot be sufficient to allow the local organization assigned to one of thelocal organization's resources. In one embodiment, the computer networksecurity application may have the capability of requiring that at leastcertain global attributes require an explicit approval by a globaladministrator before they can be assigned to a resource of a localorganization. If such an attribute is requested, the local organizationmay request its use in one of its local resources, but the computernetwork security application will not allow assignment of the attributeto the resource immediately upon request. Rather, the attribute willonly be assigned to the resource in response to a global administratorapproving the request. If a global administrator denies the request, thecomputer network security application will not assign the attribute tothe resource. On the other hand, certain attributes may be pre-approved,in which case no approval request is needed. The request of that globalattribute causes the computer network security application to assign therequested global attributed to be assigned to the resource immediately.

In the preferred embodiment, a local organization that owns an attributemay indicate that the attribute may be used by certain ones of the otherlocal organizations, with any request being made to use it, in whichcase the computer network security application will permit its use withresources associated by the computer network security application withpre-approved local organization. Otherwise, the computer networksecurity application will allow an attribute not owned by a localorganization to be associated with a resource associated with that localorganization only if a request is made with the computer networksecurity application and the attribute's owner approves it with theapplication.

Attribute usage approval can be given for different resource scopes: allresources associated with the requesting local organization, a subset ofthe resources, or a single resource, and the computer network securityapplication will enforce the scope of the approval. If approval is givenfor all resources or a subset of the resources in the organization, thecomputer network security application may automatically approve a newresource that is within the approved resource scope to use the attributeat the time the resource is created.

An attribute constraint policy is used by the computer network securityapplication to determine when an attribute may be assigned to aresource. An attribute constraint policy comprises a set of rules (oneor more rules) that define a set of combination of attributes that arenot allowed to be assigned to a single resource. The constraint rulesused by the preferred embodiment of the computer network securityapplication can be specified or defined as logical expressions with“and”, “or” and “not” operators on attributes assigned to a resource.For example, the expression “ATTR1 and (ATTR2 or ATTR3)” define that aresource cannot have attribute ATTR1 and at the same time has eitherattribute ATTR2 or attribute ATTR3.

Local Organizations or Tenants

Also, stored in a database and/or file accessible by the application isinformation in a form useful by the process for identifying one or morelocal organizations that may be given authority to manage security forone or more computer network resources of the enterprise.

In one preferred embodiment, each computer network infrastructureresource, or predefined group of infrastructure resources, is associatedwith one or more local organizations that may be given some authorityfor managing it against unauthorized access. A local organization, whichmay also be referred to as a tenant, is defined using information storedin memory by, for example, the computer network security application.The local organization may represent a specific subgroup inside theenterprise, for example, a department, organization, project, and/orline of business.

In one preferred embodiment, each computing network infrastructureresource and logical object stored and managed by computer networksecurity application is associated with a local organization as its“owner.” Other local organizations, besides the owner, may have accessto the same infrastructure resource and/or logical object, but aninfrastructure resource may have only one local organization acting asits owner. A listing of resources assigned to, or owned, a localorganization is determined, or defined, by a resource scope that isstored in memory and accessible by the computer network securityapplication. A resource scope can be defined as an explicit list ofresources, or it can be can defined using implicit infrastructure groupsavailable from a cloud service provider. Some examples of possibleresource scopes that can be assigned to a local organization include thefollowing: all resources; all resources of a particular provider type(for example, all AWS instances, or all Azure VMs); all resources of aparticular provider account (for example, all resources in a particularAWS account); resources in a provider specific implicit resource group,as described above, examples of which include an AWS VPC, an OpenStackProject, an Azure resource group, an AWS availability zone, and a regionin an AWS account; and any combination of the above, for example, twoaccounts in AWS and one project in OpenStack.

User Roles

A user role can be associated with one or more users. A role defines aset of permissions that allows a user to direct the application toperform operations on objects defined within the computer networksecurity application. These objects may represent actual computing ornetwork resources, or can be logical objects, examples of which aregiven below, created using the computer network security application.Each user role is associated with one or more local organizations. Thecomputer network security application uses a set of stored localorganizations to define a set of objects that a role can see and/ormanage according to the permissions associated with the role.

Multiple roles can be defined to give different users access to thecomputer network security application on behalf of the same localorganization, thus allowing different users in a local organization tohave different permissions to manipulate the organization's objects.

When a role allows a user to use the application to access objectsassigned to multiple organizations and to create a logical object, theapplication allows the user to select and assign one of theorganizations to be the owner of the new logical object. The role canalso be configured within the application to default to a particularlocal organization, which will be assigned as the owner of a new objectif a user does not choose one. In one embodiment, the application mayalso be configured to allow a user to change the ownership of a logicalobject when a role assigned to the user allows the user access to boththe previous and new organization and permits the user to perform thisaction with the application.

Communication Policy Rules and Constraints

A communication policy rule is one type of logical object that can beused by the computer network security application for configuringcomputer network security mechanism to allow or disallow communicationsto or from a computer network resource. A communication policy iscomprised of one or more rules that specify whether to allow and/orblock network communication to or from a particular infrastructureresource. In addition to the common parameters of logical object, acommunication policy rule has the following parameters: a logical groupthat defines the infrastructure resources that should have the policy;and a list of rules.

Each communication policy rule has the following parameters:

a. A target, which is a remote site or resource with which communicationis to be allowed.

b. One or more protocols, which may be, for example the particularprotocol that allowed traffic can use. Examples of such protocolsinclude that are part of the IP suite of protocols, such as TCP, UDP,and ICMP.

c. One or more destination ports for TCP and UDP protocols (ignored forother protocols).

d. A direction for the flow of the network traffic. For example, inboundwould be communication initiated from the remote target to one or moreresources in a logical group. Outbound would be a communicationinitiated from a resource in the logical group to the remote target.

e. An action, which either allows or blocks the network traffic based onmatching or not matching the other parameters for identifying apermitted or unauthorized flow of packets to or from the infrastructureresource rule.

f. An optional time specification defining the times when the rule isactive. This can be specified as a single occurrence with start time andduration, or a periodic time interval that repeats over an arbitraryperiod (for example 8 am-5 pm of weekdays, or every Sunday, or every5^(th) day of the month, etc.). If no time is specified, the rule isactive all the time.

The target of a communications policy rule can be one of two types: alogical group, in which case the rule applies to communication flows toor from all resources members of the logical group; or a network zone,in which case the rule applies to communication flows to or fromresources assigned to a network address (e.g. an IP address) within arange or ranges associated with the network zone.

The computer network security application will, in one embodiment,generate and provision rules to one or more infrastructure networksecurity enforcement mechanisms within the computer system'sinfrastructure that will allow communication between two points in thenetwork only allowed if there is a policy rule that explicitly allowsthat communication and there is no rule that explicitly blocks it.

A role for a user can be defined within an embodiment of the computernetwork security application to allow a user assigned the role to haveaccess, using the application, to all communication policies owned bylocal organizations that the role has access to. For those communicationpolicies the role can permit the user to read and/or modify using thecomputer network security application the communication policies basedon the privileges assigned to the role. In addition, the computernetwork security application is programmed to allow a user assigned arole to access in read-only mode (regardless of the role privileges)policies for which attributes (of the associated logical group) arepublic or exported to a local organization that the role can access. Theattributes do not need to be approved to have read access privilege tothe corresponding communication policies associated with the attributes.

A role can only create policies that are allowed by a set ofconstraints, called communication constraint policies. Each organizationhas a constraint policy which limit the type of policies that can becreated for that organization. Constraint policies create constraintsthat are enforced by the computer network security application for“allow” rules in communication policies. A similar set of “block”constraint rules can be used by the computer network securityapplication to constrain the type of “block” rules that can be createdin communication policies.

In this embodiment of the computer network security application, theapplication is programmed to permit a local organization (through a userhaving a role with appropriate privileges) to create a communicationpolicy rule for a resource only if it is explicitly allowed by aconstraint communication policy rule and is not explicitly blocked by aconstraint communication policy rule. A communication constraint policyis set by the global organization. With it the computer network securityapplication may automatically check communication policy rules createdfor local organizations for compliance with global security policies.

A constraint communication policy rule may have one or more of thefollowing fields or parameters:

a. Resource scope. The resource scope defines the resources that can usethe policy. If not defined, the rule applies to any resource in theowner organization. If the resource scope is defined, the resource scopemust be contained by the local organization. For example, if a localorganization resource scope includes two AWS accounts, the rule scopeneed to specify only one of the AWS accounts. In that case, onlyresources in that one AWS account are allowed by the computer networksecurity application to use the policy.

b. Target type. Examples of target type in representative examples of acomputer network software application implementing this feature include:a logical group, which allows the remote target to be defined as alogical group; and network address, which allows the remote target to bespecified using network zone.

c. Target resource scope (Only if the target type is logical group).This is similar to a resource scope, but for the remote target.

d. Network address range (Only if the target type is network address).This specifies one or more ranges of network addresses, in such as IPaddresses, that can be used in a policy rule.

e. Maximum size of address ranges (Only if target type is networkaddress). This limits the size of the ranges specified in the networkzone used in a communication policy rule. Not only the address ranges inthe network zone have to be contained by the IP address range in theconstraint rule, but each address range cannot have a size larger thanthe specified maximum. This allows, for example, rules with individualIP addresses in the IP address range (if maximum size is 1), but nosubnet ranges even if the subnet is contained in the IP address range.If no maximum is needed this could be set to the size of the IP addressrange, allowing the full range to be used in a communication policyrule.

f. Protocol. The communications protocol to which the communicationspolicy constraint rule would apply. Typically, for a computer network,this will be one of the protocols in the suite of IP protocols, examplesof which are TCP, UDP, and ICMP.

g. Port. This field allows specification of a single port, a range ofports, or all ports.

h. Direction. This field specifies the direction of the flow of packetsconstituting the communication. It can be inbound or outbound.

i. Action. This identifies the action that can be taken by thecommunication policy rule when the communication policy rule is matched.The actions include allow and block.

Assigning Attributes to Resources

Turning now to FIGS. 9 to 12, these figures processes for implementingan automated mechanism within computer network security application forassigning an attribute to a resource. These processes associate anattribute to a resource by mapping the attribute to infrastructure tagsor properties of the resource. The flow chart of FIG. 9 illustrates anoverview of the basic steps of the entire process 900, while FIGS. 10 to12 provide additional details of parts of the process.

Referring now to FIG. 9, the computer network security application isable to automatically map an attribute to a resource using a propertythat an actual infrastructure resource possesses, or an infrastructuretag stored by the infrastructure service provider for thatinfrastructure resource. When a new resource or a change to theproperties of existing resource is discovered by the computer networksecurity application, as represented by block 902, this triggering eventor condition causes the process 900 to be performed. Discovery can takeplace by, for example, the computer network security applicationidentifying, or being notified of, a change in one or more databasesstoring information on the computer network's infrastructure resourcesand their properties, or by querying, for example, an infrastructureservice provider's API. The computer network security application orother process may construct, add or update the store of infrastructureresources using their properties using any of the methods identifiedherein, and perform process 900 in response to those actions.

Each attribute in a list of attributes that the resource can access ischecked by the computer network security application to verify if any ofthe properties of the resource match the attribute, as represented bystep 904. If an attribute is explicitly assigned to a resource eitherdirectly or through membership in logical groups process, as indicatedby decision step 906, the attribute is checked to verify if the resourceis approved to use the attribute at step 908.

If the resource is not approved to use the attribute, the computernetwork security application can, at step 910, generate an automatedrequest for approval, depending on a pre-configured choice. If a requestis generated and sent, the attribute is added to a pending list for thatresource at step 912. If the attribute is not approved, an approvalrequest is not generated and the process ends for that attribute.Although not indicated in the flow chart, the process will repeat,starting with step 906, for the next attribute if there are anyremaining attributes to be checked. If a request is generated, thecomputer network security application then waits for a response for auser assigned the necessary role to approve or deny the request. If theattribute request is denied at step 912, the computer network securityapplication removes attribute from the list of pending attributes atstep 914 and the process ends for that attribute.

If the attribute has been previously approved for use with the resource,or if a request for approval is given, the computer security networkapplication checks at step 916 whether the attribute is not allowed byany attribute constraint policy rule, considering the attributes alreadyassigned to the resource. If the attribute is not allowed, then theprocess ends for that attribute. If the attribute is allowed, then theattribute is assigned to the resource as step 918. As indicated bydecision step 920, the process is repeated for each attribute.

FIGS. 10 to 12 describe representative examples of implementations ofvarious steps of process 900.

FIG. 10 illustrates a process 1000 performed by the computer networksecurity application for automatically assigning tags based ondiscovered tags or resource properties. The process automaticallyassociates an attribute to a resource by mapping the attribute toinfrastructure tags or properties learned from a discovered or changedresource. When a new resource is discovered, or when properties ofexisting resources change, at step 1002 the list of attributes that theresource can access are checked to verify if any of the properties ofthe resource match the attribute. As indicated by step 1004, thecomputer network security application obtains the identity of the localorganization that owns that resource. The computer software securityapplication scans all attributes to which that particular localorganization has access to at step 1006. As indicated by decision step1008 and step 1010, if there is at least one attribute that theorganization has access to, the process gets the first one. It thendetermines at step 1012 whether the attribute has been mapped to aresource property or tag. A resource property or tag is learned from theinfrastructure service provider hosting the resource. Next, as indicatedby decision step 1014, the process determines whether the resourcesatisfies the property or has a tag defined for the attribute. If itdoes, the process proceeds to determine, as indicated by decision step1016, whether the resource already has the attribute as an assigned orpending attribute. If it does, the process proceeds to step 1018, whereit jumps to an attribute assignment process 1200 that is described inFIG. 12.

If, at decision step 1014, the process determines that the resource doesnot satisfy the property or does not have a tag defined for theattribute, it proceeds to determine, at step 1020, whether the resourcehas the attribute assigned to it or has a pending attribute assigned toit. If yes, the process removes assignment of the attribute to theresource at step 1022. If no, the process returns to step 1008 andrepeats until all attributes are processed, at which point it ends.

Referring now to FIG. 11, process 1100 sets up the step of indirectassignment of tags based on logical group membership. Process istriggered at step 1102 by the addition of a resource (“RSR”) to alogical group (“LG”). At step 1104, the process scans all “assigned”attributes associated with the logical group. If, as indicated bydecision step 1106 and step 1108, there is at least one attribute, thenext attribute (“ATTR”) is obtained, the process determines for thatattribute whether the resource already has that attribute is an assignedor pending attribute at decision step 1110. If it does, the process getsthe next attribute. Otherwise, the process calls at step 1112 anattribute assignment process 1200.

Referring now to FIG. 12, illustrated are steps of the attributeassignment process 1200 for assigning an attribute to a resource. Asindicated by decision step 1202, the process determines whether theattribute is approved for the source. If it is, the process proceeds toapplying any attribute constraint rules at step 1204. It scans all ofthe possibly applicable attribute constraint rules. As indicated by theloop formed by decision step 1206, step 1208 and step 1210, theassignment of the attribute to the resource is checked against eachconstraint rule (“CRULE”). If the assignment of the attribute to theresource passes all attribute constraint rules, the process proceeds tostep 1220 and assigns the attribute to the resource. The process thenends.

If, at step 1202, the attribute is not approved for that resource,process determines, as indicated by decision step 1212, whether thecomputer network security application is configured for automaticapproval requests. If not, attribute assignment process 1200 ends. If itis, the process proceeds to step 1214, where it requests approval forsigning the attribute to the resource. It waits at step 1216. If theresource is approved to use the attribute at step 1218, the processproceeds to step 1204, where attribute constraint rules are checked.

Application of Communication Policy Constraint Rules

Referring now to FIGS. 13-16, illustrated are representative processesperformed by the computer network security application for checking alocal organizations communication policy against communication policyconstraints established by the global organization.

Process 1300 of FIG. 13 represents a basic, top-level process fordescribing how a constrained policy is used by the computer networksecurity application program to check a “self service” security policy(in this example, a communication policy) created by an organizationwithin an enterprise. As indicated by step 1302, processes triggered bya local organization creating its own communication policy. As indicatedby step 1304, the process scans all proposed rules defined within theproposed “self-service” security policy. As represented by decision step1306 in step 1308, the process checks each proposed rule (“PRULE”) inthe security policy at step 1310. At step 1310, the computer networksecurity application performs process 1400 shown in FIG. 14 determineswhether or not the rule is allowed based on the constraint policies. Ifthe rule is allowed, it is marked as being allowed at step 1312. If itis not allowed, it is marked as being not allowed at step 1314. Thecomputer network security application, as indicated by step 1316, thenenforces the rules of the security policy marked as allowed, and itignores the rules marked as not allowed. Examples of how a computernetwork security application can deploy or provision, and/or enforce, acommunication policy rules described above in connection with FIGS. 1 to8.

However, the computer network security application can also be used toread security policies already deployed using an infrastructure serviceprovider's native security mechanisms (for example using AWS webconsole) rather than with the computer network security application.When a native security mechanism is deployed by some other manner,process 1300 does not perform step 1316 and instead stores an indicationof which rules do not comply. It may generate one or more messages toalert or notify predetermined users of the computer network securityapplication of the violation of the constraint policies. The users canthen, if they desire, handle the violation as desired, such as byremoving the security policy, editing the security policy forcompliance, removing the non-compliant rule, or allowing thenon-compliant rule to remain.

Referring now to FIG. 14, the process 1400 is a representative exampleof a process for determining whether a communication policy rule isallowed using a constraint policy applicable to a local organization.This process is applied at steps 1310 in process 1300. When the processis starts at step 1402, the process gets at step 1406 the constraintpolicy for the local organization creating the communications policycontaining that rule. The process scans, at step 1408, all constraintrules within the constraint policy obtained at step 1406 with an “allow”action. As indicated by decision step 1410, step 1412, and step 1414,for each “allow” constraint rule (“ALLOWCR”) rule matching process iscarried out until there is a match with an “allow” constraint rule, atwhich point the process continues to step 1416. Process 1500, shown inFIG. 15, is an example of such a rule matching process. If the “allow”constraint rule is matched, the process 1500 returns a true. If theprocess returns a “false,” the process returns to step 1410, where thenext “allow” constraint rule is obtained and checked at step 1414 for amatch. If none of the “allow” constraint rules are a match, the processreturns as step 1415 a “false” to step 1310 of process 1300 and stops.

If the communication policy rule matches any of the “allow” constraintrules, process 1400 moves to step 1416 to check the communication policyrule against all “block” constraint rules. At step 1416, the processscans all constraint rules with the action “block.” As indicated bydecision step 1418, step 1420 and decision step 1422, the process doesloop for each “block” constraint rule (“BLOCKCR”) to check thecommunication policy rule against each “block” constraint rule using amatching process, an example of which is process 1600 of FIG. 16, untilthere is a constraint rule that is matched or there are no moreconstraint rules. If a “block” constraint rules is matched, the processmoves to step 1424 and returns a “false.” Otherwise, as indicated bystep 1426, the process returns a “true.” The process 1300 uses thereturned value at step 1310.

Referring now to FIG. 15, which illustrates the “allow” communicationconstraint rule matching process 1500, once the process starts at step1502, it gets at step 1504 a logical group for the communication policyfor the communication policy rule being matched. Then, at step 1506,they get the resource scope (“RSCOPE”) for the communication constraintpolicy containing the “allow” communication constraint rules. Then, asrepresented by decision steps 1508, 1510, and 1512, the process checkswhether all the resources in logical group contained in the resourcescope, whether the proposed communications policy rule being checkedhave the same direction and protocol as indicated in the communicationconstraint rule, and whether the “allow” communication policy constraintrule contains all of the ports in the proposed communication policy rule(“PRULE.port”) being checked. If the answer to any of the questions isnegative, meaning that the proposed communications policy rule does fitwithin these parameters in the communications constraint policy rule,the process returns a false at step 1518.

At steps 1514 and 1516, process 1500 determines which of two branches tofollow. First, if at decision step 1514, the process determines that thetarget of the proposed communication policy rule and the target in the“allow” communication policy constraint rule are logical groups, theprocess branches to the process starting with step 1520. At step 1520and 1522, the process gets the target logical groups (“TLG”) for theproposed communication policy rule and the target resource scope(“TSCOPE”) for the “allow” communication constraint policy rule. If theprocess determines at decision step 1524 all the resources in thelogical group are contained in the target resource group of the “allow”communication constrain policy rule, the process returns a “true” atstep 1526, meaning that there is a match. Otherwise it returns at step1528 a “false.”

However, if the process determines at step 1514 that the target of theproposed communication policy rule and the target in the “allow”communication policy constraint rule are not both logical groups, theprocess checks the decision at step 1516 whether the target of theproposed communication policy rule is a network zone and the target ofthe in the “allow” communications constraint rule is a IP address range.If either are not, the process returns a “false” at step 1518. If theyboth are, the process proceeds to steps 1530 and 1532. At these stepsthe process obtains the target network zone (“NETZ”) for the proposedcommunication policy constraint rule, and the IP address range (“RANGE”)for the “allow” communication policy constraint rule. Furthermore, atstep 1534, the process gets the maximum IP range size (“MAXSZ”) for the“allow” communication policy constraint rule. At step 1536, processdetermines whether the range of IP addresses contained in the networkzone for the proposed communication policy rule is contained within theIP address range for the “allow” communication policy constraint rule.If it is, the process then checks at decision step 1538 whether thesizes of each of the ranges in the target network zones for the proposedcommunication policy rule are less than or equal to the maximum IP rangesize specified in the “allow” communication policy constraint rule. Ifso, the process returns at step 1540 a “true.” Otherwise, the processreturns at step 1542 a “false.”

Turning now FIG. 16, process 1600 illustrates the basic steps of anexample of a process for matching a particular “block” communicationconstraint rule with a proposed communication policy rule. This process,or sub-process, may be used at step 1422 in process 1400 shown in FIG.14. Process 1600 starts at step 1602, when it is called or invoked. Likethe process 1500 shown in FIG. 15, process 1600 checks whether certainparameters of the proposed communication policy rule are consistentwith, or match, the parameters contained in the communication constraintpolicy rule. At step 1604, it gets the logical group (“LG”) for thepolicy containing the proposed communication policy rule that is beingevaluated. It also gets, at step 1606, the resource scope (“RSCOPE”) forthe communication constraint policy containing the “block” communicationconstraint policy rule (“BLOCKCR”) that is being applied during thematching process. As indicated by step 1608, the process then determineswhether any resource within the logical group is contained in theresource scope. If not, the process returns “false” at step 1618. A“false” return means that the proposed communication policy rule is notblocked by the communication policy constraint rule being evaluated.Otherwise, the process proceeds to check whether both the proposedcommunication policy rule and the communication policy constraint rulematch in terms of direction and protocol at step 1610. If these do notmatch, the process returns “false” at step 1618. Otherwise, at step1612, the checks whether any port in the proposed communications policyrule matches a port, or is within a range of ports (“BLOCKCR.port”),specified by the “block” communications policy constraint rule. Again,if there is no match, the process returns a “false” at step 1618.

The process then determines at step 1614 whether target specified byboth the proposed communication policy rule and “block” communicationpolicy constraint rule are both logical groups. If not, the processproceeds to decision step 1616. Otherwise, the process gets at step 1618the target logical group (“TLG”) for the proposed communication policyrule and gets at step 1620 the target resource scope (“TSCOPE”) for the“block” communication policy constraint rule. The process evaluates atstep 1622 whether any resource in the logical group for the proposedcommunication policy rule is contained within the target resource scopeof the “block” communication policy constraint rule. If not, the processreturns a “false” at step 1624. Otherwise, the process returns a “true”at step 1626, which indicates that the proposed communication policyrule is blocked by the communication policy constraint rule.

If, at step 1614 the process decides that both the proposedcommunication policy rule and the “block” communication policyconstraint rule do not have logical groups as targets, it proceeds tostep 1616 determine whether the proposed communication policy rule has atarget network zone and the “block” communication policy constraint rulespecifies in IP address range. If not, there is no match, and theprocess returns a “false” at step 1618. Otherwise, the process continuesat steps 1628 and 1630 to get the target network zone (“NETZ”) for theproposed medication policy rule and the IP address range (“RANGE”) forthe “block” communication policy constraint rule. At step 1632, theprocess evaluates whether any range defined in the target network zoneof the proposed communication policy rule has any overlap with the IPaddress range of the communication policy constraint rule. If not, theblock rule is not matched, and the process returns a “false” at step1634. Otherwise, the communication policy constraint rule is matched,and the process returns a “true” at step 1636.

The following is an example of a typical use case of local organizationsin a large enterprise. This is just one way that local organizations canbe used, but not the only one. Different enterprises can useorganizations in many other different ways. In a typical deployment, theenterprise may create a global organization to host global policies tobe used across the enterprise, and have many local organizationsassociated with different groups in the enterprise, such as lines ofbusiness, departments, and/or projects.

Global security administrators can then be given access to allorganizations, including the global organization and can be assignedpermission to do the following global tasks: create and deleteorganizations; create global attributes and make them public for globaluse, or export them to specific organizations that need to use them;create global policies and make them available across the organizationsthrough public or exported attributes; pre-approve usage of public orexported attributes by others or all organizations; approve or denyrequest to use public/exported attributes not pre-approved; defineglobal communication constraint policies and assign them to theorganizations, limiting the policies that can be created by theorganizations assigned to specific line of business or departments; anddefine attribute constraint rules for global and exported attributes.

A local organization associated with a particular line of business ordepartment can assign policies to its resources using one of thefollowing methods. First, it may select a global policy available to theorganization through public or exported attributes. In this case theorganization cannot modify the policy and can only use policies that arepre-defined. It may also create its own policies, in which case thelocal organization can create its own specific policies, but thesepolicies must be allowed by constraints defined by the globalorganization.

The foregoing description is of representative examples apparatus andprocesses that implement various features. The invention is defined bythe appended claims and is not limited to details of the representativeimplementations described above. Alterations and modifications to theexamples can be made without departing from the invention as defined bythe claims. The meaning of the terms used in this specification are,unless expressly stated otherwise, intended to have ordinary andcustomary meaning to someone of ordinary skill in the pertinent field,and are not intended to be limited to the details of the structures andprocesses given as examples.

What is claimed is:
 1. In a computer network comprised of plurality ofinterconnected computing nodes, each node running at least one work loadunit of an application workload and at least one network securitymechanism for controlling data flows to the interconnected computingnodes of the computer network, a computer implemented method forenforcing a plurality of security policies for the computer networkusing the network security mechanism, the method executing on or morecomputers in communication with the network and comprising: for each ofat least one infrastructure resources of an infrastructure serviceprovider, assigning one or more attributes to the infrastructureresource using information from the infrastructure service provider,each attribute comprising a key and value for the key using information,and selecting the infrastructure resource as a member of in one or morelogical groups using the one or more attributes; and computing aconfiguration for the at least one network security mechanism using theplurality of security policies and the infrastructure resources that aremembers of each of the logical groups to which each of the plurality ofsecurity policies applies; wherein assigning one or more attributes tothe infrastructure resource using information from the infrastructureservice provider comprises obtaining a predefined list of attributes towhich an owner of the infrastructure resource has access and, for eachattribute on the list, checking whether the attribute is mapped to aproperty or tag received from an infrastructure service provider, andwhether, using the information from the infrastructure service provider,the infrastructure resource satisfies the resource property or tag. 2.In a computer network comprised of plurality of interconnected computingnodes, each node running at least one work load unit of an applicationworkload and at least one network security mechanism for controllingdata flows to the interconnected computing nodes of the computernetwork, a computer implemented method for enforcing a plurality ofsecurity policies for the computer network using the network securitymechanism, the method executing on or more computers in communicationwith the network and comprising: for each of at least one infrastructureresources of an infrastructure service provider, assigning one or moreattributes to the infrastructure resource using information from theinfrastructure service provider, each attribute comprising a key andvalue for the key using information, and selecting the infrastructureresource as a member of in one or more logical groups using the one ormore attributes; and computing a configuration for the at least onenetwork security mechanism using the plurality of security policies andthe infrastructure resources that are members of each of the logicalgroups to which each the plurality of security policies applies; whereinassigning one or more attributes to the infrastructure resource usinginformation from the infrastructure service provider comprisesdetermining whether the infrastructure resource is allowed to use theattribute before being assigned the attribute.
 3. The method of claim 2,wherein assigning one or more attributes to the infrastructure resourcefurther comprises requesting permission for the infrastructure resourceto use the attribute.
 4. In a computer network comprised of a pluralityof interconnected computing nodes, each node running at least one workload unit of an application workload and at least one network securitymechanism for controlling data flows to the interconnected computingnodes of the computer network, a computer implemented method forenforcing a plurality of security policies for the computer networkusing the network security mechanism, the method executing on or morecomputers in communication with the network and comprising: for each ofat least one infrastructure resources of an infrastructure serviceprovider, assigning one or more attributes to the infrastructureresource using information from the infrastructure service provider,each attribute comprising a key and value for the key using information,and selecting the infrastructure source as a member of in one or morelogical groups using the one or more attributes; and computing aconfiguration for at least one network security mechanism using theplurality of security policies and the infrastructure resources that aremembers of each of the logical groups to which each the plurality ofsecurity policies applies; wherein assigning one or more attributes tothe infrastructure resource comprises determining whether theinfrastructure resource is constrained by a constraint rule from usingan attribute before being assigned the attribute.
 5. The method of claim1, wherein each of the security policies specifies a plurality of rulesspecified with logical objects.
 6. In a computer network comprised ofplurality of interconnected computing nodes, each node running at leastone work load unit of an application workload and at least one networksecurity mechanism for controlling data flows to the interconnectedcomputing nodes of the computer network, a computer implemented methodfor enforcing a plurality of security policies for the computer networkusing the network security mechanism, the method executing on or morecomputers in communication with the network and comprising: for each ofat least one infrastructure resources of an infrastructure serviceprovider, assigning one or more attributes to the infrastructureresource using information from the infrastructure service provider,each attribute comprising a key and value for the key using information,and selecting the infrastructure resource as a member of in one or morelogical groups using the one or more attributes; and computing aconfiguration for the at least one network security mechanism using theplurality of security policies and the infrastructure resources that aremembers of each of the logical groups to which each the plurality ofsecurity policies applies; wherein each of the at least two of theworkloads is running on a virtual computer hosted on a different one ofa plurality of different infrastructure service providers, and whereinthe at least one security mechanism includes a native security mechanismon each of the plurality infrastructure service providers.
 7. In anenterprise computer network comprised of plurality of interconnectedcomputing nodes and a plurality of infrastructure resources used by aplurality of organizations within the enterprise, each node running atleast one work load unit of an application workload, a computerimplemented method for enforcing a plurality of enterprise-levelsecurity policies for the computer network while permittingorganizations within the enterprise to deploy security policies, themethod comprising: in response to receiving a proposed security policycreated by one of the plurality of organizations and containing aplurality of proposed rules, checking each proposed rule against eachrule in a constraint policy that specifies rules for the one of theplurality organizations that has created the proposed rule; and ignoringrules determined to be not allowed and enforcing the rules determined tobe allowed by the constraint policy, wherein enforcing comprisescomputing a configuration for at least one security mechanism using theallowed rules; wherein the proposed security policy targets at least onelogical group and is specified using logical objects, the logical groupcontaining as members infrastructure resources selected from theplurality of infrastructure resources using attributes assigned to theinfrastructure resources; and wherein the constraint policy defines ascope of infrastructure resources to which the rules within theconstraint policy apply.
 8. The method of claim 7, further comprisinggetting the logical group that is the target of the proposed securitypolicy and the scope of infrastructure resources for the constraintpolicy and checking for violations between members of the logical groupand members of the infrastructure resources scope.
 9. The method ofclaim 8, wherein checking a proposed rule comprises determining whetherall resources within the logical group are within the scope ofinfrastructure resources of an allow rule in the constraint policy. 10.The method of claim 9, wherein checking a proposed rule furthercomprises determining whether the proposed rule and the allow rule ofthe constraint policy rule have the same direction and protocol forcommunications.
 11. The method of claim 9, wherein checking a proposedrule further comprises getting a target logical group for the proposedrule and a target resource scope for the allow rule and determiningwhether all of the infrastructure resources within the target logicalgroup of the proposed rule are contained within the infrastructureresources scope of the allow rule.
 12. The method of claim 8, whereinchecking a proposed rule comprises determining whether any resourceswithin the logical group for the security policy are within the scope ofinfrastructure resources of a block rule.
 13. The method of claim 12,wherein checking a proposed rule comprises determining whether anyresources within the logical group for the security policy are withinthe scope of infrastructure resources of a block rule occurs afterdetermining whether all resources within the logical group are withinthe scope of infrastructure resources of an allow rule in the constraintpolicy.
 14. The method of claim 12 wherein checking a proposed rulefurther comprises getting a target logical group for the proposed ruleand a target resource scope for the block rule and determining whetherany of the infrastructure resources within the target logical group ofthe proposed rule are contained within the infrastructure resourcesscope of the block rule.
 15. In an enterprise computer network used by aplurality of organizations within the enterprise and comprised of a ofinterconnected computing nodes and a plurality of infrastructureresources, each node running at least one work load unit of anapplication workload, a computer implemented method for enforcing aplurality of enterprise-level security policies for the computer networkwhile permitting organizations within the enterprise to deploy securitypolicies, the method executing on or more computers and comprising:storing a constraint policy applicable to the organization, theconstraint policy comprising a plurality of rules and defining a scopeof infrastructure resources to which the rules within the constraintpolicy apply; and checking a security policy created by one of theplurality of organizations for compliance with the constraint policy,the security policy containing a plurality of rules targeting at leastone, predefined logical group containing as a member at least one of theplurality of infrastructure resources assigned an attribute used doselect the at least one of the plurality of infrastructure resources asa member of the logical group; wherein checking comprises comparing eachrule in the security policy against each rule in the constraint policyand storing information identifying rules that do not comply.
 16. Themethod of claim 15, further comprising getting the logical group that isthe target of the security policy and the scope of infrastructureresources for the constraint policy and checking for violations betweenmembers of the logical group and members of the scope of infrastructureresources.
 17. The method of claim 15, wherein checking a proposed rulecomprises determining whether all resources within the logical group arewithin the scope of infrastructure resources of an allow rule in theconstraint policy.
 18. The method of claim 17, wherein checking aproposed rule further comprises determining whether the proposed ruleand the allow rule of the constraint policy rule have the same directionand protocol for communications.
 19. The method of claim 17, whereinchecking a proposed rule further comprises getting a target logicalgroup for the proposed rule and a target resource scope for the allowrule and determining whether all of the infrastructure resources withinthe target logical group of the proposed rule are contained within theinfrastructure resources scope of the allow rule.
 20. The method ofclaim 15, wherein checking a proposed rule comprises determining whetherany resources within the logical group for the security policy arewithin the scope of infrastructure resources of a block rule.
 21. Themethod of claim 20, wherein checking a proposed rule comprisesdetermining whether any resources within the logical group for thesecurity policy are within the scope of infrastructure resources of ablock rule occurs after determining whether all resources within thelogical group are within the scope of infrastructure resources of anallow rule in the constraint policy.
 22. The method of claim 20 whereinchecking a proposed rule further comprises getting a target logicalgroup for the proposed rule and a target resource scope for the blockrule and determining whether any of the infrastructure resources withinthe target logical group of the proposed rule are contained within theinfrastructure resources scope of the block rule.
 23. The method ofclaim 1, wherein assignment of the one or more attributes is based on aninfrastructure tag received from an infrastructure service provider forthe infrastructure resource.
 24. The method of claim 1, wherein theassignment of one or more of the one or more attributes is based on aproperty of the infrastructure resource.
 25. The method of claim 1,further comprising, for each of the at least one infrastructureresources, assigning an attribute to the infrastructure resource basedon membership in at least one logical group.
 26. The method of claim 1,wherein computing a configuration is based on the security policiesdefined for each of the logical groups and the attributes of theinfrastructure resources that are members of the logical groups.